Menu
▾
▴
mactel-linux-devel — mactel-linux Development
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
(4) |
Mar
(135) |
Apr
(130) |
May
(82) |
Jun
(101) |
Jul
(75) |
Aug
(37) |
Sep
(28) |
Oct
(45) |
Nov
(114) |
Dec
(27) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(22) |
Feb
(60) |
Mar
(81) |
Apr
(120) |
May
(29) |
Jun
(50) |
Jul
(67) |
Aug
(41) |
Sep
(36) |
Oct
(4) |
Nov
(4) |
Dec
|
| 2008 |
Jan
(5) |
Feb
(17) |
Mar
(5) |
Apr
(6) |
May
(5) |
Jun
(9) |
Jul
(5) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: gimli <gi...@da...> - 2006-03-09 23:00:10
|
The latest mm patches makes the kernel unbootable on ma iMac. cu Edgar (gimli) Hucek Tolentino, Matthew E wrote: > gimli <> wrote: >> Hi. >> >> Do you have any idea why the kernel crashes on machines with more >> then 512 MB ram ? >> > > Can you try the latest -mm with the attached patch on your machine? > This should fix it. > > matt |
|
From: Tolentino, M. E <mat...@in...> - 2006-03-09 22:19:36
|
Matthew Garrett <> wrote: > Or, as an alternative, remove the virtual to physical mapping that > efivars does. This requires fixing up IA64 to match. I've no idea > which approach is right. There's a patch (or set of patches?) in -mm from Bjorn that does=20 this (retain the physical addresses), which I believe is the best approach. Particularly considering it alleviates a bunch of=20 back-and-forth calculations in ACPI. matt =20 |
|
From: Tolentino, M. E <mat...@in...> - 2006-03-09 22:14:12
|
gimli <> wrote: > Hi. >=20 > Do you have any idea why the kernel crashes on machines with more > then 512 MB ram ?=20 >=20 Can you try the latest -mm with the attached patch on your machine? =20 This should fix it. =20 matt |
|
From: Roberto G. <gri...@gm...> - 2006-03-09 19:51:51
|
How Can I install ubuntu from liveCD? |
|
From: Michael S. <mi...@ma...> - 2006-03-09 15:36:32
|
Good work, thank you! Michael On Mar 8, 2006, at 10:48 PM, Erik Osheim wrote: > I have modified imacfb.c so that it can take 'height' and 'width' > parameters on boot. So for instance you could say: > > video=imacfb:mini,height=1280,width=1024 > > This will override the default value that we use. > > I have tested this on my Mac Mini and it seems to work fine for me (I > can make the screen 800x600, or 1024x768, or 1280x1024). I was > thinking of making the argument something more like > "geometry=1024x768" but it turns out that parsing out height and width > separately is a lot easier. > > I am attaching the new imacfb.c. I'm not a regular kernel contributor > so maybe I formatted something wrong, but things seem reasonable to > me. Please let me know if there are problems with it. > > -- Erik > <imacfb.c> |
|
From: Erik O. <er...@pl...> - 2006-03-09 06:48:23
|
I have modified imacfb.c so that it can take 'height' and 'width' parameters on boot. So for instance you could say: video=imacfb:mini,height=1280,width=1024 This will override the default value that we use. I have tested this on my Mac Mini and it seems to work fine for me (I can make the screen 800x600, or 1024x768, or 1280x1024). I was thinking of making the argument something more like "geometry=1024x768" but it turns out that parsing out height and width separately is a lot easier. I am attaching the new imacfb.c. I'm not a regular kernel contributor so maybe I formatted something wrong, but things seem reasonable to me. Please let me know if there are problems with it. -- Erik |
|
From: Erik O. <er...@pl...> - 2006-03-09 01:01:47
|
OK, some more feedback on the mac mini frame buffer: It seems like the screen dimensions aren't being calculated correctly. I think Michael alluded to this earlier. Using a 15" dell flat screen monitor I get about 17 lines or so below the bottom of the screen, and about 33 characters that don't fit on the side. I'm not a kernel expert, but if someone points me to the right part of the code I can try to get it working and test it on my machine. Or if someone wants to send another patch, those are always fun and easy! One other question: is there a chance the VESA framebuffer driver would work, or is that not possible. I tried it earlier and it didn't seem to work but you guys may know something I don't. Thanks again. -- Erik |
|
From: Michael S. <mi...@ma...> - 2006-03-08 22:11:41
|
> append="video=imacfb:mini imacfb=mini acpi=force" > > Not sure if "imacfb=mini" does anything, but "video=imacfb:mini" is > definitely necessary. Sorry, you are right, of course it needs to be video=imacfb:mini Michael |
|
From: Erik O. <er...@pl...> - 2006-03-08 21:01:03
|
So I built this new kernel and booted it. The graphics seemed to come
up nicely.
I ended up using the following in elilo.conf:
image=bzImage
label=Linux
description="Linux"
initrd=initrd.gz
append="video=imacfb:mini imacfb=mini acpi=force"
Not sure if "imacfb=mini" does anything, but "video=imacfb:mini" is
definitely necessary.
Once I did boot I saw that my initrd filesystem had issues and wasn't
compatible with the way that the fstab was set up. I'm not sure which
way I want to go next; I'll probably try to run the machine off my USB
memory stick for now.
Thanks for the help!
-- Erik
P.S. The ViewCVS on sourceforge isn't showing the new
patches/etc. yet. I applied Michael Steil's patch myself, but others
may not be able to get at it.
On Wed, Mar 08, 2006 at 09:59:27AM -0500, Erik Osheim wrote:
> Great! I will give this a shot.
>
> As far as building the kernel goes, I assume I should not have any
> modules and just try dumping a monolithic kernel on my USB boot
> device?
>
> Thanks,
>
> -- Erik
>
> On Wed, Mar 08, 2006 at 12:24:39AM -0800, Michael Steil wrote:
> > Hi!
> >
> > Done that. The Mac mini framebuffer is always 2048 pixels wide, no
> > matter how wide the screen is. So all you need to do is modify
> > imacfb.c to support a mode like this:
> >
> > case M_MINI:
> > screen_info.lfb_width = 1024;
> > screen_info.lfb_height = 768;
> > screen_info.lfb_linelength = 2048 * 4;
> > break;
> >
> > This way, it will always *use* 1024x768, no matter how big the screen
> > really is. We would need UGA calls to find that out.
> >
> > I've attached the altered version of imacfb.c. use imacfb=mini on the
> > command line. Gimli, can you please merge?
> >
> > Michael
> >
>
>
> >
> > On Mar 7, 2006, at 7:53 PM, Erik Osheim wrote:
> >
> > >Hey I have an Intel mac mini. I've been hoping to boot Linux on it,
> > >but so far haven't had much luck. I *have* gotten the rEFIt boot
> > >loader (and shell) to work; I think the problem had to do with the
> > >kernel I had (I think it expected a Radeon graphics card rather than
> > >the Intel one).
> > >
> > >Anyone working on this? I would be happy to look at things if someone
> > >could get me started, or try stuff that someone else has.
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Mactel-linux-devel mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/mactel-linux-devel
|
|
From: Erik O. <er...@pl...> - 2006-03-08 14:59:44
|
Great! I will give this a shot. As far as building the kernel goes, I assume I should not have any modules and just try dumping a monolithic kernel on my USB boot device? Thanks, -- Erik On Wed, Mar 08, 2006 at 12:24:39AM -0800, Michael Steil wrote: > Hi! > > Done that. The Mac mini framebuffer is always 2048 pixels wide, no > matter how wide the screen is. So all you need to do is modify > imacfb.c to support a mode like this: > > case M_MINI: > screen_info.lfb_width = 1024; > screen_info.lfb_height = 768; > screen_info.lfb_linelength = 2048 * 4; > break; > > This way, it will always *use* 1024x768, no matter how big the screen > really is. We would need UGA calls to find that out. > > I've attached the altered version of imacfb.c. use imacfb=mini on the > command line. Gimli, can you please merge? > > Michael > > > On Mar 7, 2006, at 7:53 PM, Erik Osheim wrote: > > >Hey I have an Intel mac mini. I've been hoping to boot Linux on it, > >but so far haven't had much luck. I *have* gotten the rEFIt boot > >loader (and shell) to work; I think the problem had to do with the > >kernel I had (I think it expected a Radeon graphics card rather than > >the Intel one). > > > >Anyone working on this? I would be happy to look at things if someone > >could get me started, or try stuff that someone else has. > |
|
From: Matthew G. <mj...@sr...> - 2006-03-08 12:30:03
|
DMI lets us tell the difference between different classes of Intel Mac fairly easily (imac, mac mini, macbook), but isn't terribly helpful when it comes to determining which specific model (eg, 17" or 20") we have access to. It would be helpful if we could either: a) probe the size of the LCD directly, or b) at least be able to tell the difference between the same models but with different sized screens I haven't been able to find any way to do this yet. Has anyone else had any success? -- Matthew Garrett | mj...@sr... |
|
From: Roberto G. <gri...@gm...> - 2006-03-08 12:08:15
|
Yesterday i've try to boot liveCD on MacBook Pro with success result, but the power save don't work very well. |
|
From: gimli <gi...@da...> - 2006-03-08 09:25:28
|
Merged into CVS. Nice work. cu gimli Michael Steil wrote: > Hi! > > Done that. The Mac mini framebuffer is always 2048 pixels wide, no > matter how wide the screen is. So all you need to do is modify imacfb.c > to support a mode like this: > > case M_MINI: > screen_info.lfb_width = 1024; > screen_info.lfb_height = 768; > screen_info.lfb_linelength = 2048 * 4; > break; > > This way, it will always *use* 1024x768, no matter how big the screen > really is. We would need UGA calls to find that out. > > I've attached the altered version of imacfb.c. use imacfb=mini on the > command line. Gimli, can you please merge? > > Michael > > > On Mar 7, 2006, at 7:53 PM, Erik Osheim wrote: > >> Hey I have an Intel mac mini. I've been hoping to boot Linux on it, >> but so far haven't had much luck. I *have* gotten the rEFIt boot >> loader (and shell) to work; I think the problem had to do with the >> kernel I had (I think it expected a Radeon graphics card rather than >> the Intel one). >> >> Anyone working on this? I would be happy to look at things if someone >> could get me started, or try stuff that someone else has. > |
|
From: Michael S. <mi...@ma...> - 2006-03-08 08:24:59
|
Hi! Done that. The Mac mini framebuffer is always 2048 pixels wide, no matter how wide the screen is. So all you need to do is modify imacfb.c to support a mode like this: case M_MINI: screen_info.lfb_width = 1024; screen_info.lfb_height = 768; screen_info.lfb_linelength = 2048 * 4; break; This way, it will always *use* 1024x768, no matter how big the screen really is. We would need UGA calls to find that out. I've attached the altered version of imacfb.c. use imacfb=mini on the command line. Gimli, can you please merge? Michael |
|
From: Erik O. <er...@pl...> - 2006-03-08 03:53:47
|
Hey I have an Intel mac mini. I've been hoping to boot Linux on it, but so far haven't had much luck. I *have* gotten the rEFIt boot loader (and shell) to work; I think the problem had to do with the kernel I had (I think it expected a Radeon graphics card rather than the Intel one). Anyone working on this? I would be happy to look at things if someone could get me started, or try stuff that someone else has. If someone knows a good way to try booting a kernel without having a display driver (just to see if the boot loader/etc. works) please let me know. I will work on this on my own in the meantime. Thanks, -- Erik |
|
From: gimli <gi...@da...> - 2006-03-07 20:40:06
|
Great work Chris. cu gimli Christoph Pfisterer wrote: > Hi all, > > I've registered a SourceForge project for rEFIt. The current source code > is now checked into the project's Subversion repository: > > http://sourceforge.net/svn/?group_id=161917 > > I plan to make a new release after working on the error handling. After > that I'll take a look at porting parted or GRUB's file system code. > > So long, > chrisp > > --chrisp a.k.a. Christoph Pfisterer "To understand a program > cp...@ch... - http://chrisp.de you must become both the > PGP key & geek code available machine and the program." > ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Mactel-linux-devel mailing list Mac...@li... https://lists.sourceforge.net/lists/listinfo/mactel-linux-devel |
|
From: Christoph P. <cp...@ch...> - 2006-03-07 20:38:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I've registered a SourceForge project for rEFIt. The current source code is now checked into the project's Subversion repository: http://sourceforge.net/svn/?group_id=161917 I plan to make a new release after working on the error handling. After that I'll take a look at porting parted or GRUB's file system code. So long, chrisp - -- chrisp a.k.a. Christoph Pfisterer "To understand a program cp...@ch... - http://chrisp.de you must become both the PGP key & geek code available machine and the program." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEDe8Zr/EAHkwpC28RAhQvAKDDrKfuodoh+qz68wH6nDvg0ZamqACfVNxn oZS0rcujw7avAnh0+rFt5ss= =kVT3 -----END PGP SIGNATURE----- |
|
From: gimli <gi...@da...> - 2006-03-07 09:09:22
|
Hi. The new LiveCD is up at http://sourceforge.net/project/showfiles.php?group_id=160126&package_id=181927 cu gimli |
|
From: Matthew G. <mj...@sr...> - 2006-03-06 19:02:05
|
On Mon, Mar 06, 2006 at 07:37:04PM +0100, gimli wrote: > Hi. > > If i select "Memory split (3G/1G user/kernel split (for full 1G low memory))" the kernel also boots. Hm. That's actually a 2.75:1.25 split. It's still not entirely ideal. It would be nice to figure out what's actually going on here - my suspicion would still be that something is confused between physical and virtual addresses. -- Matthew Garrett | mj...@sr... |
|
From: gimli <gi...@da...> - 2006-03-06 18:37:08
|
Hi. If i select "Memory split (3G/1G user/kernel split (for full 1G low memory))" the kernel also boots. cu gimli Matthew Garrett wrote: > On Mon, Mar 06, 2006 at 07:00:33PM +0100, gimli wrote: >> Nope. It was the Memory Split from 3G/1G to 2G/2G. > > Ah, interesting. Does this imply some sort of confusion between physical > addresses and virtual addresses? There would presumably still be > problems on 2GB machines, and certain bits of userspace software break > if the split is changed, so it's not an ideal long-term solution... > |
|
From: Matthew G. <mj...@sr...> - 2006-03-06 18:05:56
|
On Mon, Mar 06, 2006 at 07:00:33PM +0100, gimli wrote: > Nope. It was the Memory Split from 3G/1G to 2G/2G. Ah, interesting. Does this imply some sort of confusion between physical addresses and virtual addresses? There would presumably still be problems on 2GB machines, and certain bits of userspace software break if the split is changed, so it's not an ideal long-term solution... -- Matthew Garrett | mj...@sr... |
|
From: gimli <gi...@da...> - 2006-03-06 18:00:39
|
Nope. It was the Memory Split from 3G/1G to 2G/2G. cu gimli Matthew Garrett wrote: > On Mon, Mar 06, 2006 at 05:27:05PM +0100, gimli wrote: >> I have some good news. First i have found a workaround for >> Intel Macs with more than 512 MB ram. > > Hi, > > Any chance you could let me know what this fix was? Just enabling > HIGHMEM4G? > |
|
From: Matthew G. <mj...@sr...> - 2006-03-06 17:05:36
|
On Mon, Mar 06, 2006 at 05:27:05PM +0100, gimli wrote: > Today i had the chance to boot the CD on a Macbook pro. There > was one big surprise. This model didn't use the Broadcom WLAN > chip. I saw an atheros chip in lspci. It seems to be an Atheros 5424, which is a PCI Express part. It's (in theory) supported by the madwifi-ng code. -- Matthew Garrett | mj...@sr... |
|
From: Matthew G. <mj...@sr...> - 2006-03-06 16:42:59
|
On Mon, Mar 06, 2006 at 05:27:05PM +0100, gimli wrote: > I have some good news. First i have found a workaround for > Intel Macs with more than 512 MB ram. Hi, Any chance you could let me know what this fix was? Just enabling HIGHMEM4G? -- Matthew Garrett | mj...@sr... |
|
From: gimli <gi...@da...> - 2006-03-06 16:27:08
|
I have some good news. First i have found a workaround for Intel Macs with more than 512 MB ram. I work on a new Live CD with updated kernel and the rEFIt bootloader. Today i had the chance to boot the CD on a Macbook pro. There was one big surprise. This model didn't use the Broadcom WLAN chip. I saw an atheros chip in lspci. There is a new patch in CVS with the latest patches from Matthew Garrett and and also a new kernel config which makes the boot on > 512MB ram possible. cu gimli |
71 messages has been excluded from this view by a project administrator.
