Menu
▾
▴
mac-on-linux-devel — Development discussion
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
(4) |
May
(7) |
Jun
(7) |
Jul
(16) |
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2009 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(11) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
(19) |
Nov
|
Dec
|
| 2011 |
Jan
(3) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2015 |
Jan
(4) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(1) |
Jun
(4) |
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Joseph J. <jo...@ge...> - 2007-07-29 23:21:38
|
Andreas Schwab wrote: > Elimar Riesebieter <rie...@lx...> writes: > >> building the modules gives >> >> WARNING: "handle_mm_fault" [/usr/src/modules/mol/kmod/mol.ko] undefined! > > That symbol has explicitly been removed from the exported list of the > kernel, on the ground that nobody is using it (which is true in the > context of the kernel sources). > > Andreas. > Okay. It's kind of fundamental for MOL. MOL causes faults by executing a bogus instruction to setup the mmu for guest execution. The handler is used if the requested page is not present. Christoph, since you were the one that submitted the patch for removal, would you mind if we re-added the export for handle_mm_fault? Thanks, -Joe |
|
From: Andreas S. <sc...@su...> - 2007-07-29 21:52:31
|
didier <di...@gm...> writes: > I'm seeing the same on Ubuntu Gutsy for me the pb is with > #define _LARGEFILE64_SOURCE > in drivers/disk/include/blk_dmg.h Feature test macros must be defined _before_ any standard header has been included. Andreas. -- Andreas Schwab, SuSE Labs, sc...@su... SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." |
|
From: didier <di...@gm...> - 2007-07-29 21:27:05
|
I'm seeing the same on Ubuntu Gutsy for me the pb is with #define _LARGEFILE64_SOURCE in drivers/disk/include/blk_dmg.h it compiles without it and seems to work but I don't have compressed images. Didier |
|
From: Andreas S. <sc...@su...> - 2007-07-29 20:43:57
|
Elimar Riesebieter <rie...@lx...> writes: > building the modules gives > > WARNING: "handle_mm_fault" [/usr/src/modules/mol/kmod/mol.ko] undefined! That symbol has explicitly been removed from the exported list of the kernel, on the ground that nobody is using it (which is true in the context of the kernel sources). Andreas. -- Andreas Schwab, SuSE Labs, sc...@su... SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." |
|
From: Elimar R. <rie...@lx...> - 2007-07-29 19:25:07
|
On Sun, 29 Jul 2007 the mental interface of Mark Brown told: [...] > Note that I've no idea what version of Mac on Linux Elimar was > experiencing trouble with and have been entirely unable to reproduce the > problem he is reporting. If someone could provide reproduction > instructions or (better yet) a cut down test case I could have a look. zlib1g 1.2.3.3 libc6 2.6 linux 2.6.23-rc1 Elimar -- Numeric stability is probably not all that important when you're guessing;-) |
|
From: Joseph J. <jo...@ge...> - 2007-07-29 18:54:11
|
> Whatever is going on there is no way that including stdio.h prior to > zlib.h should break anything (or be required for that matter). I've > just had a brief look and as far as I can tell it works perfectly well > with either _LARGEFILE64_SOURCE or _FILE_OFFSET_BITS set with both 1.2.3 > and 1.2.3.3 (the latter is what's in Debian unstable but is a > pre-release so most people are at 1.2.3). If there *are* problems with > the zlib headers it would be best to work out what they are and try to > resolve them prior to the next zlib release. > > The only thing I can think that might break is if blk_dmg.h tries to set > one or the other of those defines after stdio.h has been included. > > Note that I've no idea what version of Mac on Linux Elimar was > experiencing trouble with and have been entirely unable to reproduce the > problem he is reporting. If someone could provide reproduction > instructions or (better yet) a cut down test case I could have a look. > > Note also that the gzio API in zlib prior to 1.2.3.mumble prereleases > doesn't cope with large files at all, though you don't seem to be using > it so that shouldn't be an issue. > I've also been unable to reproduce it here on Gentoo. To be honest, I don't see how including/not including stdio.h should make a difference either way, which is why I just removed it. Again, if a FC7 user would like to test the current SVN for me, I'd appreciate it. Thanks, -Joe |
|
From: Mark B. <br...@de...> - 2007-07-29 18:49:52
|
On Sun, Jul 29, 2007 at 12:18:15PM -0400, Joseph Jezak wrote: >> -#include <stdio.h> >> #include "blk_dmg.h" > Well, that's wicked annoying. I added that to fix build errors on FC7. = =20 > I've reverted that change, can someone running FC7 see if it still builds= =20 > and if not, please post the whole error. Whatever is going on there is no way that including stdio.h prior to zlib.h should break anything (or be required for that matter). I've just had a brief look and as far as I can tell it works perfectly well with either _LARGEFILE64_SOURCE or _FILE_OFFSET_BITS set with both 1.2.3 and 1.2.3.3 (the latter is what's in Debian unstable but is a pre-release so most people are at 1.2.3). If there *are* problems with the zlib headers it would be best to work out what they are and try to resolve them prior to the next zlib release. The only thing I can think that might break is if blk_dmg.h tries to set one or the other of those defines after stdio.h has been included. Note that I've no idea what version of Mac on Linux Elimar was experiencing trouble with and have been entirely unable to reproduce the problem he is reporting. If someone could provide reproduction instructions or (better yet) a cut down test case I could have a look. Note also that the gzio API in zlib prior to 1.2.3.mumble prereleases doesn't cope with large files at all, though you don't seem to be using it so that shouldn't be an issue. --=20 "You grabbed my hand and we fell into it, like a daydream - or a fever." |
|
From: Elimar R. <rie...@lx...> - 2007-07-29 17:05:46
|
On Sun, 29 Jul 2007 the mental interface of
Joseph Jezak told:
[...]
> Please make a bug for this on the project page, I'll look into it
> later tonight.
Done:)
Thanks
Elimar
--
"Talking much about oneself can also
be a means to conceal oneself."
-Friedrich Nietzsche
|
|
From: Joseph J. <jo...@ge...> - 2007-07-29 16:18:23
|
> The following patch did the trick! > > > diff -ur a/src/drivers/disk/blk_dmg.c b/src/drivers/disk/blk_dmg.c > --- a/src/drivers/disk/blk_dmg.c 2007-07-29 17:42:08.000000000 +0200 > +++ b/src/drivers/disk/blk_dmg.c 2007-07-29 17:42:33.000000000 +0200 > @@ -26,7 +26,6 @@ > * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN > * THE SOFTWARE. > */ > -#include <stdio.h> > #include "blk_dmg.h" > > /* Read 64 bit value */ > > Well, that's wicked annoying. I added that to fix build errors on FC7. I've reverted that change, can someone running FC7 see if it still builds and if not, please post the whole error. Thanks! -Joe |
|
From: Elimar R. <rie...@lx...> - 2007-07-29 16:07:55
|
Hi all,
building the modules gives
WARNING: "handle_mm_fault" [/usr/src/modules/mol/kmod/mol.ko] undefined!
Loading mol gives:
insmod /lib/modules/2.6.23-rc1-git6-aragorn/extra/mol.ko
mol: Unknown symbol handle_mm_fault
FATAL: Error inserting mol (/lib/modules/2.6.23-rc1-git6-aragorn/extra/mol.ko):
Unknown symbol in module, or unknown parameter (see dmesg)
Elimar
--
.~.
/V\ L I N U X
/( )\ >Phear the Penguin<
^^-^^
|
|
From: Joseph J. <jo...@ge...> - 2007-07-29 16:02:30
|
Elimar Riesebieter wrote: > Hi all, > > building the modules gives > > WARNING: "handle_mm_fault" [/usr/src/modules/mol/kmod/mol.ko] undefined! > > Loading mol gives: > > insmod /lib/modules/2.6.23-rc1-git6-aragorn/extra/mol.ko > mol: Unknown symbol handle_mm_fault > FATAL: Error inserting mol (/lib/modules/2.6.23-rc1-git6-aragorn/extra/mol.ko): > Unknown symbol in module, or unknown parameter (see dmesg) > > > Elimar > Please make a bug for this on the project page, I'll look into it later tonight. -Joe |
|
From: Elimar R. <rie...@lx...> - 2007-07-29 15:52:36
|
Hi all,
building the modules gives
WARNING: "handle_mm_fault" [/usr/src/modules/mol/kmod/mol.ko] undefined!
Loading mol gives:
insmod /lib/modules/2.6.23-rc1-git6-aragorn/extra/mol.ko
mol: Unknown symbol handle_mm_fault
FATAL: Error inserting mol (/lib/modules/2.6.23-rc1-git6-aragorn/extra/mol.ko):
Unknown symbol in module, or unknown parameter (see dmesg)
Elimar
--
.~.
/V\ L I N U X
/( )\ >Phear the Penguin<
^^-^^
|
|
From: Elimar R. <rie...@lx...> - 2007-07-29 15:46:12
|
On Sun, 29 Jul 2007 the mental interface of
Joseph Jezak told:
> Elimar Riesebieter wrote:
> > Compiling blk_dmg.o
> > In file included from ./include/blk_dmg.h:37,
> > from blk_dmg.c:30:
> > /usr/include/zlib.h:1366: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gzseek64'
> > /usr/include/zlib.h:1367: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gztell64'
> > /usr/include/zlib.h:1368: error: expected declaration specifiers or '...' before 'off64_t'
> > /usr/include/zlib.h:1369: error: expected declaration specifiers or '...' before 'off64_t'
> > make[3]: *** [../../../obj-ppc/build/src/drivers/disk/blk_dmg.o] Error 1
> > make[2]: *** [sub-disk-all] Error 2
> > make[1]: *** [sub-drivers-all] Error 2
> > make: *** [sub-src-all] Error 2
> >
> > Any hints?
> >
> > Elimar
> >
> >
>
> It's not a MOL issue. Your zlib headers are broken when
> -D_LARGE_FILES is enabled. You can either turn off -D_LARGE_FILES
> in the MOL Makefile, or fix your headers.
The following patch did the trick!
diff -ur a/src/drivers/disk/blk_dmg.c b/src/drivers/disk/blk_dmg.c
--- a/src/drivers/disk/blk_dmg.c 2007-07-29 17:42:08.000000000 +0200
+++ b/src/drivers/disk/blk_dmg.c 2007-07-29 17:42:33.000000000 +0200
@@ -26,7 +26,6 @@
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
-#include <stdio.h>
#include "blk_dmg.h"
/* Read 64 bit value */
--
"Talking much about oneself can also
be a means to conceal oneself."
-Friedrich Nietzsche
|
|
From: Joseph J. <jo...@ge...> - 2007-07-29 13:13:32
|
Elimar Riesebieter wrote: > Compiling blk_dmg.o > In file included from ./include/blk_dmg.h:37, > from blk_dmg.c:30: > /usr/include/zlib.h:1366: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gzseek64' > /usr/include/zlib.h:1367: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gztell64' > /usr/include/zlib.h:1368: error: expected declaration specifiers or '...' before 'off64_t' > /usr/include/zlib.h:1369: error: expected declaration specifiers or '...' before 'off64_t' > make[3]: *** [../../../obj-ppc/build/src/drivers/disk/blk_dmg.o] Error 1 > make[2]: *** [sub-disk-all] Error 2 > make[1]: *** [sub-drivers-all] Error 2 > make: *** [sub-src-all] Error 2 > > Any hints? > > Elimar > > It's not a MOL issue. Your zlib headers are broken when -D_LARGE_FILES is enabled. You can either turn off -D_LARGE_FILES in the MOL Makefile, or fix your headers. -Joe |
|
From: Elimar R. <rie...@lx...> - 2007-07-29 13:01:05
|
Compiling blk_dmg.o
In file included from ./include/blk_dmg.h:37,
from blk_dmg.c:30:
/usr/include/zlib.h:1366: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gzseek64'
/usr/include/zlib.h:1367: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gztell64'
/usr/include/zlib.h:1368: error: expected declaration specifiers or '...' before 'off64_t'
/usr/include/zlib.h:1369: error: expected declaration specifiers or '...' before 'off64_t'
make[3]: *** [../../../obj-ppc/build/src/drivers/disk/blk_dmg.o] Error 1
make[2]: *** [sub-disk-all] Error 2
make[1]: *** [sub-drivers-all] Error 2
make: *** [sub-src-all] Error 2
Any hints?
Elimar
--
Learned men are the cisterns of knowledge,
not the fountainheads ;-)
|
|
From: Joseph J. <jo...@ge...> - 2007-06-25 17:11:25
|
> What's left to the SDL video driver? It's just not finished yet, I've been a bit busy outside of MOL and haven't had time to clean it up and get it in. And by finishing the UI do you > mean a cocoa UI for the OSX release or a common UI (perhaps in SDL)? ndansmith is currently working on a common UI. Currently there are gtk and ncurses frontends. The current version is available in SVN and I'm sure he'd like feedback! -Joe |
|
From: Joseph J. <jo...@ge...> - 2007-06-25 14:30:34
|
Andreas Schwab wrote:
> Joseph Jezak <jo...@ge...> writes:
>
>> I've already fixed this in SVN. Please try that and let me know if
>> it works for you.
>
> The changes in find_physical_rom are not complete, AFAIK. I don't think
> you can use dn->next for finding the next node, instead you have to
> repeat of_find_by_name or of_find_by_name, resp. Also, there are calls
> to of_node_put missing.
>
> Andreas.
>
> --- dev.c
> +++ dev.c
> @@ -72,18 +72,27 @@ find_physical_rom( int *base, int *size
> #ifndef CONFIG_AMIGAONE
> struct device_node *dn;
> int len, *p;
> + int by_type = 0;
>
> - if( !(dn=find_devices("boot-rom")) && !(dn=find_type_devices("rom")) )
> + dn = of_find_node_by_name(NULL, "boot-rom");
> + if (!dn) {
> + by_type = 1;
> + dn = of_find_node_by_type(NULL, "rom");
> + }
> + if (!dn)
> return 0;
> do {
> - if( !(p=(int*)get_property(dn, "reg", &len)) || len != sizeof(int[2]) )
> + if( !(p=(int*)get_property(dn, "reg", &len)) || len != sizeof(int[2]) ) {
> + of_node_put(dn);
> return 0;
> + }
> if( (unsigned int)(0xfff00100 - p[0]) < (unsigned int)p[1] ) {
> *base = p[0];
> *size = p[1];
> + of_node_put(dn);
> return 1;
> }
> - dn = dn->next;
> + dn = by_type ? of_find_node_by_type(dn, "rom") : of_find_node_by_name(dn, "boot-rom");
> } while( dn );
> #endif
>
>
Sorry about not getting back to you sooner, I've added your
suggestion to SVN, thanks!
-Joe
|
|
From: Joseph J. <jo...@ge...> - 2007-06-25 13:25:37
|
> So: > - Does isochronous transfer work? I'm not sure, I haven't really looked at the USB code yet. > - In USB prober KLog.ext panic OSX guest when I'm trying to capture > the traffic, it's my setup or it never works? Which probing tool are you using exactly? How can I try this myself? > - How hard would it be to add an input in MOLAudio OSX driver? I'm looking into this now. I think I might move to use OpenAL instead of the ALSA/OSS/SDL drivers we have now. -Joe |
|
From: Joseph J. <jo...@ge...> - 2007-06-25 13:25:16
|
Vo Spader wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Yes. The sources for Mac-on-Mac have already been checked into the > Mac-on-Linux SVN. If I recall correctly, we are waiting for Joe to > finish the BootX drivers for OSX. Yeah, that either needs to be resolved, but it's not pressing since we can just use a binary. I also want to finish the native video driver (SDL Video) and finish the user interface before we do an OSX release. -Joe |
|
From: Vo S. <ter...@gm...> - 2007-06-16 15:07:24
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes. The sources for Mac-on-Mac have already been checked into the Mac-on-Linux SVN. If I recall correctly, we are waiting for Joe to finish the BootX drivers for OSX. suppa wrote: > Hi, > is an OS X port scheduled ? > > I found the sources for Mac-on-Mac that's stuck on Tiger, I'd like to > have a "virtualizator" on my PPC, as I would install other systems > (like linux or openbsd) running at native speed and without the need > to reboot OS X. > > I couldn't get a clear answer browsing on web. > > Thanks > > > Andrea > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Mac-on-linux-devel mailing list > Mac...@li... > https://lists.sourceforge.net/lists/listinfo/mac-on-linux-devel > - -- #Vo Spader -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGc/yle8NxSJVh16oRAltbAKDz8kr+bM1CuR9jU5Ucb9sO4UF1vwCeOJCP Qkfpa2HuBV0UnUK+2LtZyhk= =e719 -----END PGP SIGNATURE----- |
|
From: suppa <su...@em...> - 2007-06-16 11:11:28
|
Hi, is an OS X port scheduled ? I found the sources for Mac-on-Mac that's stuck on Tiger, I'd like to have a "virtualizator" on my PPC, as I would install other systems (like linux or openbsd) running at native speed and without the need to reboot OS X. I couldn't get a clear answer browsing on web. Thanks Andrea |
|
From: didier <di...@gm...> - 2007-06-11 09:41:48
|
Hi,
I'm running MOL svn HEAD and an Ubuntu box with linux 2.6.22 with
tiger as guest and I'm trying to use a webcam (I only want to use the
mic).
The mic works in Linux or when booting OSX but not in MOL.
- if by mistake I don't remove snd_usb_audio, the first call to
usbdev.c:usb_connect_probe() only fails on claiming interface 1 not 0
so I get a lot of :
usbfs: process 20977 (mol) did not claim interface 2 before use
in syslog and OSX doesn't fully see the micro anyway.
I don't know if it's a linux/driver bug but if it's a normal behavior
something like:
for( iface=0; iface<10; iface++ )
if( ioctl(fd, USBDEVFS_CLAIMINTERFACE,
&iface) < 0 ) {
if (errno == EBUSY) {
iface = 0;
}
break;
}
seems to work.
- without the module, OSX finds the micro (USB prober or control
panel) but it never start transfer.
So:
- Does isochronous transfer work?
- In USB prober KLog.ext panic OSX guest when I'm trying to capture
the traffic, it's my setup or it never works?
- How hard would it be to add an input in MOLAudio OSX driver?
Didier
|
|
From: Elimar R. <rie...@lx...> - 2007-05-28 07:28:16
|
On Sun, 27 May 2007 the mental interface of Elimar Riesebieter told: [...] > <*> IRQ vectorCanBeShared 3 > <*> IRQ vectorCanBeShared 4 > <*> IRQ vectorCanBeShared 2 > <*> Block Driver v1.1 > <*> IRQ vectorCanBeShared 5 > <*> Ethernet driver 1.1 > <*> IRQ vectorCanBeShared 24 > <*> MolAudio 1.2 > <*> IRQ vectorCanBeShared 1 > cleaning up... > Terminating threads... > DONE IP_NAT wasn't configured. Now it works perfect. Thanks Elimar -- Numeric stability is probably not all that important when you're guessing;-) |
|
From: Elimar R. <rie...@lx...> - 2007-05-27 18:33:48
|
On Sat, 26 May 2007 the mental interface of Joseph Jezak told: > Elimar Riesebieter wrote: [...] > > WARNING: /usr/src/modules/mol/debian/mol-modules-2.6.22-rc3-aragorn/lib/modules/2.6.22-rc3-aragorn/extra/mol.ko needs unknown symbol find_devices > > WARNING: /usr/src/modules/mol/debian/mol-modules-2.6.22-rc3-aragorn/lib/modules/2.6.22-rc3-aragorn/extra/mol.ko needs unknown symbol find_type_devices > > > > Any hints? > > I've already fixed this in SVN. Please try that and let me know if > it works for you. The module builds fine, but running startmol -X: >> ================================================== >> MacOS X Boot Loader 0.9.73-SVN >> Candidate boot volume: /mol-blk@0/disk@0:0 >> /mol-blk@0/disk@0:0,\mach_kernel (4347724 bytes) >> Old mkext timestamp (or safe-boot) >> Loading from /mol-blk@0/disk@0:0,\System\Library\ >> ================================================== <*> IRQ vectorCanBeShared 3 <*> IRQ vectorCanBeShared 4 <*> IRQ vectorCanBeShared 2 <*> Block Driver v1.1 <*> IRQ vectorCanBeShared 5 <*> Ethernet driver 1.1 <*> IRQ vectorCanBeShared 24 <*> MolAudio 1.2 <*> IRQ vectorCanBeShared 1 cleaning up... Terminating threads... DONE Elimar -- Numeric stability is probably not all that important when you're guessing;-) |
|
From: Andreas S. <sc...@su...> - 2007-05-26 16:19:26
|
Joseph Jezak <jo...@ge...> writes:
> I've already fixed this in SVN. Please try that and let me know if
> it works for you.
The changes in find_physical_rom are not complete, AFAIK. I don't think
you can use dn->next for finding the next node, instead you have to
repeat of_find_by_name or of_find_by_name, resp. Also, there are calls
to of_node_put missing.
Andreas.
--- dev.c
+++ dev.c
@@ -72,18 +72,27 @@ find_physical_rom( int *base, int *size
#ifndef CONFIG_AMIGAONE
struct device_node *dn;
int len, *p;
+ int by_type = 0;
- if( !(dn=find_devices("boot-rom")) && !(dn=find_type_devices("rom")) )
+ dn = of_find_node_by_name(NULL, "boot-rom");
+ if (!dn) {
+ by_type = 1;
+ dn = of_find_node_by_type(NULL, "rom");
+ }
+ if (!dn)
return 0;
do {
- if( !(p=(int*)get_property(dn, "reg", &len)) || len != sizeof(int[2]) )
+ if( !(p=(int*)get_property(dn, "reg", &len)) || len != sizeof(int[2]) ) {
+ of_node_put(dn);
return 0;
+ }
if( (unsigned int)(0xfff00100 - p[0]) < (unsigned int)p[1] ) {
*base = p[0];
*size = p[1];
+ of_node_put(dn);
return 1;
}
- dn = dn->next;
+ dn = by_type ? of_find_node_by_type(dn, "rom") : of_find_node_by_name(dn, "boot-rom");
} while( dn );
#endif
--
Andreas Schwab, SuSE Labs, sc...@su...
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
|
13 messages has been excluded from this view by a project administrator.
