* Re: jffs2 robustness against powerfailure
From: David Woodhouse @ 2005-10-17 12:37 UTC (permalink / raw)
To: David Jander; +Cc: linux-mtd, linuxppc-embedded
In-Reply-To: <200510141135.47186.david.jander@protonic.nl>
On Fri, 2005-10-14 at 11:35 +0200, David Jander wrote:
> We have a custom embedded linux board, based on a MPC852T processor, running
> 2.4.25 kernel from denx. Jffs2 has certain backported patches after cvs from
> 03/2005.
That sounds like a recipe for pain. March 2005 wasn't a good time to
take a snapshot from CVS; that just happens to be the time that we
stopped bothering to make it build in obsolete kernels.
If you want _stable_ JFFS2 code, you should use the code which is in the
2.4.31 kernel, or use the code which is in the 2.6 kernel (perhaps
updated from current CVS).
> How comes I get a to see a valid file containing a mix of old and new
> data if it was written with a single write() call?????
Linux doesn't guarantee atomicity of writes larger than a single page,
but since your case is smaller than a page, it should have been atomic.
> Shouldn't jffs2 throw away the new incomplete node and keep the old
> version of the file?
Yes, it should. It's acceptable that there are extra data in the file
after 0x300 bytes, because the test program first does a write() call
and then a subsequent truncate() call. But it's not expected that the
0x300-byte write was not atomic; except in certain circumstances (like
reaching the end of an eraseblock and writing a smaller node there) you
should have seen all of it, or none.
Please could you reproduce on a sane kernel and show the output of the
checkfs program during your test just before the power down, and also if
possible take an image of the contents of the flash _before_ mounting it
again after the power cycle. I'd like to see precisely the log nodes
which were present on the flash. If it's difficult to take a snapshot
before remounting, then running with CONFIG_JFFS2_FS_DEBUG=1 and
capturing all the KERN_DEBUG output via a serial console would suffice.
--
dwmw2
^ permalink raw reply
* flash for lite5200
From: Alessandro Rubini @ 2005-10-17 16:42 UTC (permalink / raw)
To: linuxppc-embedded
Hello.
I'm using linux-2.6.14-rc3-g4c234921 from denx, and I need to access
the flash device. While in 2.4 there is drivers/mtd/maps/icecube.c
(by Wolfgang Denk himself, it seems), I managed to see the flash
using the physmap driver and cmdline partitions.
Does it make sense to add the correct MTD settings to
arch/ppc/configs/lite5200_defconfig (and some hints in
Documentation/powerpc/mpc52xx.txt) without porting the whole of
maps/icecube.c or is there a specific advantage in add a file in maps?
-- well, besides having sensible partitions already ported from 2.4?
In either case, I'm willing to contribute the patch.
These are the winning settings for me, but it doesn't cope with
lite5200 speciments with 8MBi of flash (are there any still around?)
[there's more than strictly needed, actually]
CONFIG_MTD=y
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_CHAR=y
CONFIG_MTD_CFI=y
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_AMDSTD_RETRY=0
CONFIG_MTD_CFI_UTIL=y
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=0xff000000
CONFIG_MTD_PHYSMAP_LEN=0x1000000
CONFIG_MTD_PHYSMAP_BANKWIDTH=1
/alessandro
^ permalink raw reply
* Re: 2.6.13 ati (ibook) frambuffer problem
From: Joerg Dorchain @ 2005-10-17 18:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1129452167.7620.34.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]
On Sun, Oct 16, 2005 at 06:42:46PM +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2005-10-16 at 10:17 +0200, Joerg Dorchain wrote:
> > On Sat, Oct 15, 2005 at 07:58:25AM +1000, Benjamin Herrenschmidt wrote:
> > >
> > > This looks like a bug that was introduced by linus in 2.6.13 and that I
> > > _think_ should be fixed in the stable series, so if you get 2.6.13.x (x
> > > = latest stable release) it should work.
> >
> > 2.6.13.4 does not fix it and(, as far as I skimmed it,) contains no
> > changes to the ati framebuffer code.
>
> Hrm... annoying, I was sure it was fixed, I'll have to check. The bug
> isn't actually in the ATI code, but in the PCI code. Well, maybe you are
> hitting something else...
It seems.
>
> The bug I'm thinking about was fixed by git commit
> 6821eb3b64158ec230982f4db5f027b326edd620, here's the patch. Let me know
> if it helps.
This patch is contained in 2.6.13.4. It did not help.
I selected
CONFIG_FB
CONFIG_FB_RADEON
CONFIG_FB_RADEON_I2C
CONFIG_BACKLIGHT_LCD_SUPPORT
FRAMEBUFFER_CONSOLE
The 2.6.12 version worked. Would it make sense to post the complete
.config?
Bye,
Joerg
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Announce: MPC8272ADS platform support added to mpc8260sar project.
From: Mark A. Greer @ 2005-10-17 18:44 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linux-atm-general@lists.sourceforge.net, linuxppc-embedded
In-Reply-To: <20051017123543.51aa7d24.ajz@cambridgebroadband.com>
On Mon, Oct 17, 2005 at 12:35:43PM +0100, Alex Zeffertt wrote:
> Hi lists,
>
> I'm writing to let anybody (who may be interested) know that I've
> added support for the MPC8272ADS platform to the mpc8260sar ATM device
> driver:
>
> http://mpc8260sar.sourceforge.net
There is already an ads8272_defconfig in the kernel.org tree and AFAIK
it works. Did you add some functionality or change something? Or am
I missing something?
Mark
^ permalink raw reply
* Re: ELDK 3.1.1 ramdisk
From: Wolfgang Denk @ 2005-10-17 20:08 UTC (permalink / raw)
To: somshekar chandrashekar kadam; +Cc: linuxppc-embedded
In-Reply-To: <20051017075208.29624.qmail@webmail24.rediffmail.com>
In message <20051017075208.29624.qmail@webmail24.rediffmail.com> you wrote:
>
> I am using MPC862 with 64mb ram , with Denx 3.1.1 eldk
> with linux-2.4.25 on my custom board.
> on Uboot i use SMC2 as my seri
> al console , when i load linux i use SCC4 as my serisl console , this is be
> cuase i dont have any idea why my SMC2 is not working , it works fine on my
> linux-2.4.18 kernel ,
> anyways thats not the problem ,
Yes it is. It is a major mistake to ignore one problem and to try to
continue and then complain about other, later issues.
Fix one problem at a time.
Do not try to continue before fixing the console problem.
> i am using r
> amdisk_image.gz provided by eldk , and i have configured kernel wit intial
> ramdisk support , i have attachec the config file below , and also the boot
> ing messages in another file . as i chnages the console from smc2 to scc4 f
> rom uboot to linux may be intial message is not clear ,
It is not only not clear, but unreadable. Like most of your message,
btw. Please fix your mailer.
> i always get ker
> nel panic VFS unable to mount root fs , is there something else i need to d
> o or i am missing very important configuartion , please throw some light
Which exact boot arguments did you pass?
You configure for a MBX board - is this *really* one of these old
door stoppers?
Try removing devfs support and CONFIG_CMDLINE_BOOL and CONFIG_CMDLINE
from your configuration.
Best regards,
Viele Grüße,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Everyting looks interesting until you do it. Then you find it's just
another job. - Terry Pratchett, _Moving Pictures_
^ permalink raw reply
* Re: 2.6.13 ati (ibook) frambuffer problem
From: Benjamin Herrenschmidt @ 2005-10-17 21:44 UTC (permalink / raw)
To: Joerg Dorchain; +Cc: linuxppc-dev
In-Reply-To: <20051017183443.GB28756@Redstar.dorchain.net>
> I selected
>
> CONFIG_FB
> CONFIG_FB_RADEON
> CONFIG_FB_RADEON_I2C
> CONFIG_BACKLIGHT_LCD_SUPPORT
> FRAMEBUFFER_CONSOLE
>
> The 2.6.12 version worked. Would it make sense to post the complete
> .config?
Nope. What may help is a bit more debugging. For example, does the
kernel actually boots if you add "video=ofonly" to the kernel command
line.
Next would be to hack kernel/printk.c to call btext_drawstring() on the
printk buffer, though you'd have to add a global variable "foo" that you
test before doing that, and only set it to 1 from pmac_setup_arch() in
arch/ppc/platforms/pmac_setup.c
Ben.
^ permalink raw reply
* Re: merge progress
From: Simon Richter @ 2005-10-17 22:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17235.33942.754076.419504@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]
Hi,
Paul Mackerras schrieb:
> Hmmm, probably should work off the merge tree.
Good, then I'll fast-forward them there.
> However, we decided at
> OLS that platforms would require a device tree before being merged.
> Have you looked at creating a suitable flattened device tree blob with
> dtc? (If not, you can continue to compile with ARCH=ppc for now.)
In fact my current plan is to move away from m68k bootinfo (which APUS
borrows so you can use the same bootloader) towards a flattened dev tree
passed in from the bootloader. For that, however, we need a new
bootloader first, which is dependant on AmigaOS binutils/gcc.
So I guess it will be ARCH=ppc until the new bootloader is ready.
Should APUS still get a special treatment then, or should I try to
emulate enough of OF in the bootloader so it is possible to build CHRP
images that work on APUS?
Simon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 374 bytes --]
^ permalink raw reply
* Re: merge progress
From: Kumar Gala @ 2005-10-17 22:39 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <17235.33942.754076.419504@cargo.ozlabs.ibm.com>
> Hmmm, probably should work off the merge tree. However, we decided at
> OLS that platforms would require a device tree before being merged.
> Have you looked at creating a suitable flattened device tree blob with
> dtc? (If not, you can continue to compile with ARCH=ppc for now.)
That would assume the ARCH=ppc builds in the merge tree. Paul, stop
breaking ARCH=ppc just because your annoyed at me for killing 970 and
POWER4 in the cputable :)
syscalls has issues in ARCH=ppc.
- kumar
^ permalink raw reply
* Re: merge progress
From: Geert Uytterhoeven @ 2005-10-18 7:50 UTC (permalink / raw)
To: Simon Richter
Cc: Linux/PPC Development, Linux/PPC on APUS development,
linuxppc64-dev
In-Reply-To: <4354235B.8090608@hogyros.de>
On Tue, 18 Oct 2005, Simon Richter wrote:
> Paul Mackerras schrieb:
> > Hmmm, probably should work off the merge tree.
>
> Good, then I'll fast-forward them there.
>
> > However, we decided at
> > OLS that platforms would require a device tree before being merged.
> > Have you looked at creating a suitable flattened device tree blob with
> > dtc? (If not, you can continue to compile with ARCH=ppc for now.)
>
> In fact my current plan is to move away from m68k bootinfo (which APUS
> borrows so you can use the same bootloader) towards a flattened dev tree
Is requiring a flattened device tree really the right approach to take, for
APUS? APUS borrows from/shares with m68k a lot of code.
BTW, why do you want to move away from m68k bootinfo (apart from using a
flattened device tree)?
> passed in from the bootloader. For that, however, we need a new
> bootloader first, which is dependant on AmigaOS binutils/gcc.
>
> So I guess it will be ARCH=ppc until the new bootloader is ready.
Happy hacking!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Newbie... in mailing lists...
From: David Woodhouse @ 2005-10-18 7:53 UTC (permalink / raw)
To: Nathael PAJANI; +Cc: linuxppc-embedded
In-Reply-To: <43539813.8010809@cpe.fr>
On Mon, 2005-10-17 at 14:24 +0200, Nathael PAJANI wrote:
> I tried to reply to this thread:
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-October/020555.html
> But it created a new one..... not good.
That's a problem with the archives; it's not your fault. If you look at
the mailto: link at the top of that page, you see it looks like this:
mailto:linuxppc-embedded%40ozlabs.org?Subject=eldk%203.1.1%20ramdisk%20image%20problem&In-Reply-To=
Although it _attempts_ to set the In-Reply-To: header which would make
your message appear to be a reply to the mail in the archive, it seems
to be missing the actual message-id of that mail; it's just empty.
> I tried to look for advices on posting and replying on the mailling list...
> but the links given there:
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> for the rules (http://lists.linuxppc.org/rules.html) and posting
> guidlines (http://lists.linuxppc.org/guidelines.html) are down.
The rules are fairly much the same everywhere -- not only for mailing
lists but for email in general. Try http://david.woodhou.se/email.html
if you think you need to read about it, perhaps.
--
dwmw2
^ permalink raw reply
* RE: fs_enet driver - me too
From: Schaefer-Hutter, Peter @ 2005-10-18 7:51 UTC (permalink / raw)
To: linuxppc-embedded
Rune Torgersen wrote:
> Does anybody have a working patchset for fs_enet for 2.6.12?
>=20
> The patches I've found on this list (and on ozlab's patch list) I
> cannot get to compile.
Any news?
Regards,
=20
Peter
^ permalink raw reply
* Need help Understanding initial memory conditions.
From: David H. Lynch Jr @ 2005-10-18 8:04 UTC (permalink / raw)
To: linuxppc-embedded
What exactly is the minimal startup system state the Linux 2.6.13
Kernel expects ?
I am trying to bring up a xilinx V4 ppc 405 board.
It has flash based at 0x0 and DRAM based at ox98000000.
I already have a working monitor/program loader and a filesystem of
the flash. I can fairly easily compile and load onto the filesystem and
run standalone PPC apps on the board.
All memory is as configured by the base hardware. The MMU, BAT, ...
are all at their powerup state.
I have put together a Linux config based heavily on an abbreviated
version of the Xilinx ML-300 config.
If I try to load it it just goes bye-bye.
I am trying to decipher the initial machine state Linux 2.6.13 expects.
u-boot seems to completely setup the MMU, but also seems to expect
to start execution from flash or ROM.
scanning the Linux code seems to indicate that the only entry that
needs to be setup for the MMU is the one for block Linux starts
executing out of.
I am also being somewhat confused by references to physical address
0 and virtual address 0xc000000.
I thought Linux executed from virtual address 0, and the actual
physical address was a function of the hardware.
^ permalink raw reply
* Re: Announce: MPC8272ADS platform support added to mpc8260sar project.
From: Alex Zeffertt @ 2005-10-18 8:47 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linux-atm-general, linuxppc-embedded
In-Reply-To: <20051017184441.GC1245@mag.az.mvista.com>
On Mon, 17 Oct 2005 11:44:41 -0700
"Mark A. Greer" <mgreer@mvista.com> wrote:
> On Mon, Oct 17, 2005 at 12:35:43PM +0100, Alex Zeffertt wrote:
> > Hi lists,
> >
> > I'm writing to let anybody (who may be interested) know that I've
> > added support for the MPC8272ADS platform to the mpc8260sar ATM
> > device driver:
> >
> > http://mpc8260sar.sourceforge.net
>
> There is already an ads8272_defconfig in the kernel.org tree and
> AFAIK it works. Did you add some functionality or change something?
> Or am I missing something?
>
I've added support for this platform to the ATM driver.
^^^^^^^^^^^^^^^^^
Alex
^ permalink raw reply
* Re: Need help Understanding initial memory conditions.
From: Kalle Pokki @ 2005-10-18 8:49 UTC (permalink / raw)
To: David H. Lynch Jr; +Cc: linuxppc-embedded
In-Reply-To: <4354AC78.5080206@comcast.net>
David H. Lynch Jr wrote:
> What exactly is the minimal startup system state the Linux 2.6.13
> Kernel expects ?
It's pretty hard to describe the system state fully, as there are so
many registers it may depend on. However, I can point out a few things
from your setup:
1. Put RAM to 0x0000000 and flash to some location it mirrors to your
boot vector. Linux always expects your physical memory to be at zero. It
is then mapped to virtual address 0xC0000000.
2. You don't need to have MMU enabled.
3. Make sure your boot arguments are passed properly to the kernel. This
includes the settings in registers r3 ... r7 and the bd_info structure .
There are many variants of that structure, make sure you use the same
ones in the boot loader and in Linux.
^ permalink raw reply
* Re: 2.6.13 ati (ibook) frambuffer problem
From: Joerg Dorchain @ 2005-10-18 8:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1129585466.7620.90.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
On Tue, Oct 18, 2005 at 07:44:26AM +1000, Benjamin Herrenschmidt wrote:
> > The 2.6.12 version worked. Would it make sense to post the complete
> > .config?
I got 2.6.13.4 booting. The last change I did was deselecting
CONFIG_FB_TILEBLITTING. Unfortunately, I have no idea how this actually
affects the ATI frambebuffer.
To make it even more strange, after reenabling CONFIG_FB_TILEBLITTING,
it still boots up cleanly. Obviously, I missed out on something.
Besides, I have the impression that the disk reacts slower. As hdparm
does not tell a difference, it might be due the coffein, tough.
>
> Nope. What may help is a bit more debugging. For example, does the
> kernel actually boots if you add "video=ofonly" to the kernel command
> line.
No effect.
Well, the good point is, it works again. The bad point, I do not know
why. Anyway, thanks for the support.
Bye,
Joerg
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: flash for lite5200
From: White @ 2005-10-18 15:22 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051017164253.GA21936@mail.gnudd.com>
The Lite5200 has an official Port to 2.6 by Sylvain Munaut
<tnt@246tNt.com>
There is an Mapping MTD driver ready.
if it's not in vanilla, you found a patchset on Mailign archive or
on Sylvain's HP.
Am Mon, 17 Oct 2005 18:42:53 +0200 schrieb Alessandro Rubini
<rubini@gnudd.com> :
>
> Hello.
>
> I'm using linux-2.6.14-rc3-g4c234921 from denx, and I need to access
> the flash device. While in 2.4 there is drivers/mtd/maps/icecube.c
> (by Wolfgang Denk himself, it seems), I managed to see the flash
> using the physmap driver and cmdline partitions.
>
> Does it make sense to add the correct MTD settings to
> arch/ppc/configs/lite5200_defconfig (and some hints in
> Documentation/powerpc/mpc52xx.txt) without porting the whole of
> maps/icecube.c or is there a specific advantage in add a file in maps?
> -- well, besides having sensible partitions already ported from 2.4?
>
> In either case, I'm willing to contribute the patch.
>
> These are the winning settings for me, but it doesn't cope with
> lite5200 speciments with 8MBi of flash (are there any still around?)
> [there's more than strictly needed, actually]
>
> CONFIG_MTD=y
> CONFIG_MTD_PARTITIONS=y
> CONFIG_MTD_CMDLINE_PARTS=y
> CONFIG_MTD_CHAR=y
> CONFIG_MTD_CFI=y
> CONFIG_MTD_GEN_PROBE=y
> CONFIG_MTD_MAP_BANK_WIDTH_1=y
> CONFIG_MTD_MAP_BANK_WIDTH_2=y
> CONFIG_MTD_MAP_BANK_WIDTH_4=y
> CONFIG_MTD_CFI_I1=y
> CONFIG_MTD_CFI_I2=y
> CONFIG_MTD_CFI_INTELEXT=y
> CONFIG_MTD_CFI_AMDSTD=y
> CONFIG_MTD_CFI_AMDSTD_RETRY=0
> CONFIG_MTD_CFI_UTIL=y
>
> CONFIG_MTD_PHYSMAP=y
> CONFIG_MTD_PHYSMAP_START=0xff000000
> CONFIG_MTD_PHYSMAP_LEN=0x1000000
> CONFIG_MTD_PHYSMAP_BANKWIDTH=1
>
>
> /alessandro
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Announce: MPC8272ADS platform support added to mpc8260sar project.
From: Mark A. Greer @ 2005-10-18 18:22 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linux-atm-general, linuxppc-embedded
In-Reply-To: <20051018094730.36aa7b99.ajz@cambridgebroadband.com>
On Tue, Oct 18, 2005 at 09:47:30AM +0100, Alex Zeffertt wrote:
> On Mon, 17 Oct 2005 11:44:41 -0700
> "Mark A. Greer" <mgreer@mvista.com> wrote:
>
> > On Mon, Oct 17, 2005 at 12:35:43PM +0100, Alex Zeffertt wrote:
> > > Hi lists,
> > >
> > > I'm writing to let anybody (who may be interested) know that I've
> > > added support for the MPC8272ADS platform to the mpc8260sar ATM
> > > device driver:
> > >
> > > http://mpc8260sar.sourceforge.net
> >
> > There is already an ads8272_defconfig in the kernel.org tree and
> > AFAIK it works. Did you add some functionality or change something?
> > Or am I missing something?
> >
>
> I've added support for this platform to the ATM driver.
> ^^^^^^^^^^^^^^^^^
Oh, duh. Sorry 'bout that.
Mark
^ permalink raw reply
* Re: [PATCH] ppc32: ppc_sys fixes for 8xx and 82xx
From: Marcelo Tosatti @ 2005-10-18 14:24 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Kumar Gala, linuxppc-embedded list
In-Reply-To: <434BC424.50700@ru.mvista.com>
Hi Vitaly,
> This patch fixes a numbers of issues regarding to that both 8xx and 82xx
> began to use ppc_sys model:
> - Platform is now identified by default deviceless SOC, if no
> BOARD_CHIP_NAME is specified in the bard-specific header. For the list
> of supported names refer to (arch/ppc/syslib/) mpc8xx_sys.c and
> mpc82xx_sys.c for 8xx and 82xx respectively.
> - Fixed a bug in identification by name - if the name was not found,
> it returned -1 instead of default deviceless ppc_spec.
> - fixed devices amount in the 8xx platform system descriptions
Patch looks good.
For 8xx, I was wondering if the PARTNUM field of the IMMR
(section 10.4.1 of MPC860UM.pdf) does have meaningful
information which could be used to identify the CPU.
^ permalink raw reply
* openpic/mac-io
From: i2a @ 2005-10-18 19:22 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am searching for documentation about the OpenPIC interrupt-controller in mac
systems. I found this site but most of the links are dead or give no hope on
real technical documentation :).
http://www.macbsd.com/openmac/refs.html
Could someone give any pointers or files?
I am also searching for any related documentation on the mac-io device (this
could be a combo document).
I am trying to do a port as a masters project, and my biggest problem is:
documentation :(.
Thanks
Ingmar.
^ permalink raw reply
* Re: Need help Understanding initial memory conditions.
From: David H. Lynch Jr. @ 2005-10-18 19:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4354B707.6060002@iki.fi>
Kalle Pokki wrote:
> David H. Lynch Jr wrote:
>
>> What exactly is the minimal startup system state the Linux 2.6.13
>> Kernel expects ?
>
>
> It's pretty hard to describe the system state fully, as there are so
> many registers it may depend on. However, I can point out a few things
> from your setup:
>
> 1. Put RAM to 0x0000000 and flash to some location it mirrors to your
> boot vector. Linux always expects your physical memory to be at zero.
> It is then mapped to virtual address 0xC0000000.
In both this list and elsewhere I have seen several references to
the difficulty setting up Linux with a physical RAM base other than 0x0.
I was hoping that I could bypass that by re-arranging physical memory
using the BAT's or MMU.
I am gathering that while this is possible, that it not sufficient. That
if memory is re-arranged after power-on it has to be done by something
Linux is not aware of.
>
> 2. You don't need to have MMU enabled.
There is a god. I am a compitent developer with lots of low level
experience, but I have thus far completely missed out on both PPC
assembler and memory management.
>
> 3. Make sure your boot arguments are passed properly to the kernel.
> This includes the settings in registers r3 ... r7 and the bd_info
> structure . There are many variants of that structure, make sure you
> use the same ones in the boot loader and in Linux.
That I should have no problem with.
>
>
Thank You very much
^ permalink raw reply
* Re: [PATCH] ppc32: ppc_sys fixes for 8xx and 82xx
From: Dan Malek @ 2005-10-18 19:46 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Kumar Gala, linuxppc-embedded list
In-Reply-To: <20051018142411.GA14065@logos.cnet>
On Oct 18, 2005, at 10:24 AM, Marcelo Tosatti wrote:
> For 8xx, I was wondering if the PARTNUM field of the IMMR
> (section 10.4.1 of MPC860UM.pdf) does have meaningful
> information which could be used to identify the CPU.
It has meaningful information, but not the way you want
to use it :-) The PARTNUM/MASKNUM is only useful
once you know the type of processor (like 823, 850, 885, etc)
The PARTNUM is only useful within the "family." For
example, the 860 and 880 are two different families, and
will contain the similar PARTNUM values through their life.
I believe it's tied to the fabrication process.
You may as well stop looking for an easy (or possibly
any) way to differentiate these parts in software, but
due to they way they are fabricated, I don't think that's
ever going to happen. :-)
-- Dan
^ permalink raw reply
* Re: Need help Understanding initial memory conditions.
From: Kalle Pokki @ 2005-10-18 20:14 UTC (permalink / raw)
To: dhlii; +Cc: linuxppc-embedded
In-Reply-To: <435549C2.1000106@dlasys.net>
David H. Lynch Jr. wrote:
> Kalle Pokki wrote:
>
>> 1. Put RAM to 0x0000000 and flash to some location it mirrors to your
>> boot vector. Linux always expects your physical memory to be at zero.
>> It is then mapped to virtual address 0xC0000000.
>
> In both this list and elsewhere I have seen several references to
> the difficulty setting up Linux with a physical RAM base other than
> 0x0. I was hoping that I could bypass that by re-arranging physical
> memory using the BAT's or MMU.
> I am gathering that while this is possible, that it not sufficient.
> That if memory is re-arranged after power-on it has to be done by
> something Linux is not aware of.
I'm afraid you cannot fool Linux that way... it will take control of the
BATs and MMU. Even as a concept, you cannot re-arrange physical memory
with the MMU at all - it's virtual memory when you do the address
translation. The only way to arrange physical memory is to program the
memory controller. I don't know how flexible the OCM controller in
ppc405 is, but I'd be surprised if one couldn't freely set the addresses
to whatever suits best.
^ permalink raw reply
* [PATCH] powerpc: Some more fixes to allow building for a Book-E processor
From: Kumar Gala @ 2005-10-18 22:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Some minor fixes that are needed if we are building for a book-e
processor.
Signed-off-by: Kumar K. Gala <kumar.gala@freescale.com>
---
commit a2084dccc9e9b0ccc5c40ed2f1273c82b23369d2
tree f1799fd89588a066ca5210d5dd65ff795ba0af0d
parent 77f543cb467c44960bafa6c91f5af75919d693e4
author Kumar K. Gala <kumar.gala@freescale.com> Tue, 18 Oct 2005 17:38:53 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Tue, 18 Oct 2005 17:38:53 -0500
arch/powerpc/kernel/Makefile | 3 ++-
arch/powerpc/mm/Makefile | 5 ++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -25,13 +25,14 @@ extra-$(CONFIG_40x) := head_4xx.o
extra-$(CONFIG_44x) := head_44x.o
extra-$(CONFIG_FSL_BOOKE) := head_fsl_booke.o
extra-$(CONFIG_8xx) := head_8xx.o
+extra-$(CONFIG_6xx) += idle_6xx.o
extra-$(CONFIG_PPC64) += entry_64.o
extra-$(CONFIG_PPC_FPU) += fpu.o
extra-y += vmlinux.lds
obj-y += process.o init_task.o \
prom.o systbl.o traps.o
-obj-$(CONFIG_PPC32) += entry_32.o idle_6xx.o setup_32.o misc_32.o
+obj-$(CONFIG_PPC32) += entry_32.o setup_32.o misc_32.o
obj-$(CONFIG_PPC64) += setup_64.o misc_64.o
obj-$(CONFIG_PPC_OF) += prom_init.o
obj-$(CONFIG_MODULES) += ppc_ksyms.o
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -7,14 +7,13 @@ EXTRA_CFLAGS += -mno-minimal-toc
endif
obj-y := fault.o mem.o lmb.o
-obj-$(CONFIG_PPC32) += init_32.o pgtable_32.o mmu_context_32.o \
- tlb_32.o
+obj-$(CONFIG_PPC32) += init_32.o pgtable_32.o mmu_context_32.o
hash-$(CONFIG_PPC_MULTIPLATFORM) := hash_native_64.o
obj-$(CONFIG_PPC64) += init_64.o pgtable_64.o mmu_context_64.o \
hash_utils_64.o hash_low_64.o tlb_64.o \
slb_low.o slb.o stab.o mmap.o imalloc.o \
$(hash-y)
-obj-$(CONFIG_PPC_STD_MMU_32) += ppc_mmu_32.o hash_low_32.o
+obj-$(CONFIG_PPC_STD_MMU_32) += ppc_mmu_32.o hash_low_32.o tlb_32.o
obj-$(CONFIG_40x) += 4xx_mmu.o
obj-$(CONFIG_44x) += 44x_mmu.o
obj-$(CONFIG_FSL_BOOKE) += fsl_booke_mmu.o
^ permalink raw reply
* [PATCH] ppc32: replace use of _GLOBAL with .globl for ppc32
From: Kumar Gala @ 2005-10-18 22:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc-embedded
The _GLOBAL() macro is for text symbols only. Changed to using
.globl for .data symbols. This is also needed in ppc32 land
to allow FSL Book-E, 40x, and 44x to work.
Signed-off-by: Kumar K. Gala <kumar.gala@freescale.com>
---
commit ca6e6d7a599f8e8a5976c044910b98ef30258e30
tree d220cd916c8bdb6bb9c5ddbdfc2ecbfa5004cf89
parent a2084dccc9e9b0ccc5c40ed2f1273c82b23369d2
author Kumar K. Gala <kumar.gala@freescale.com> Tue, 18 Oct 2005 17:40:56 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Tue, 18 Oct 2005 17:40:56 -0500
arch/ppc/kernel/head_44x.S | 18 +++++++++++-------
arch/ppc/kernel/head_4xx.S | 16 +++++++++++-----
arch/ppc/kernel/head_fsl_booke.S | 17 +++++++++++------
3 files changed, 33 insertions(+), 18 deletions(-)
diff --git a/arch/ppc/kernel/head_44x.S b/arch/ppc/kernel/head_44x.S
--- a/arch/ppc/kernel/head_44x.S
+++ b/arch/ppc/kernel/head_44x.S
@@ -743,14 +743,18 @@ _GLOBAL(set_context)
* goes at the beginning of the data segment, which is page-aligned.
*/
.data
-_GLOBAL(sdata)
-_GLOBAL(empty_zero_page)
+ .align 12
+ .globl sdata
+sdata:
+ .globl empty_zero_page
+empty_zero_page:
.space 4096
/*
* To support >32-bit physical addresses, we use an 8KB pgdir.
*/
-_GLOBAL(swapper_pg_dir)
+ .globl swapper_pg_dir
+swapper_pg_dir:
.space 8192
/* Reserved 4k for the critical exception stack & 4k for the machine
@@ -759,13 +763,15 @@ _GLOBAL(swapper_pg_dir)
.align 12
exception_stack_bottom:
.space BOOKE_EXCEPTION_STACK_SIZE
-_GLOBAL(exception_stack_top)
+ .globl exception_stack_top
+exception_stack_top:
/*
* This space gets a copy of optional info passed to us by the bootstrap
* which is used to pass parameters into the kernel like root=/dev/sda1, etc.
*/
-_GLOBAL(cmd_line)
+ .globl cmd_line
+cmd_line:
.space 512
/*
@@ -774,5 +780,3 @@ _GLOBAL(cmd_line)
*/
abatron_pteptrs:
.space 8
-
-
diff --git a/arch/ppc/kernel/head_4xx.S b/arch/ppc/kernel/head_4xx.S
--- a/arch/ppc/kernel/head_4xx.S
+++ b/arch/ppc/kernel/head_4xx.S
@@ -988,10 +988,14 @@ _GLOBAL(set_context)
* goes at the beginning of the data segment, which is page-aligned.
*/
.data
-_GLOBAL(sdata)
-_GLOBAL(empty_zero_page)
+ .align 12
+ .globl sdata
+sdata:
+ .globl empty_zero_page
+empty_zero_page:
.space 4096
-_GLOBAL(swapper_pg_dir)
+ .globl swapper_pg_dir
+swapper_pg_dir:
.space 4096
@@ -1001,12 +1005,14 @@ _GLOBAL(swapper_pg_dir)
exception_stack_bottom:
.space 4096
critical_stack_top:
-_GLOBAL(exception_stack_top)
+ .globl exception_stack_top
+exception_stack_top:
/* This space gets a copy of optional info passed to us by the bootstrap
* which is used to pass parameters into the kernel like root=/dev/sda1, etc.
*/
-_GLOBAL(cmd_line)
+ .globl cmd_line
+cmd_line:
.space 512
/* Room for two PTE pointers, usually the kernel and current user pointers
diff --git a/arch/ppc/kernel/head_fsl_booke.S b/arch/ppc/kernel/head_fsl_booke.S
--- a/arch/ppc/kernel/head_fsl_booke.S
+++ b/arch/ppc/kernel/head_fsl_booke.S
@@ -1028,10 +1028,14 @@ _GLOBAL(set_context)
* goes at the beginning of the data segment, which is page-aligned.
*/
.data
-_GLOBAL(sdata)
-_GLOBAL(empty_zero_page)
+ .align 12
+ .globl sdata
+sdata:
+ .globl empty_zero_page
+empty_zero_page:
.space 4096
-_GLOBAL(swapper_pg_dir)
+ .globl swapper_pg_dir
+swapper_pg_dir:
.space 4096
/* Reserved 4k for the critical exception stack & 4k for the machine
@@ -1040,13 +1044,15 @@ _GLOBAL(swapper_pg_dir)
.align 12
exception_stack_bottom:
.space BOOKE_EXCEPTION_STACK_SIZE * NR_CPUS
-_GLOBAL(exception_stack_top)
+ .globl exception_stack_top
+exception_stack_top:
/*
* This space gets a copy of optional info passed to us by the bootstrap
* which is used to pass parameters into the kernel like root=/dev/sda1, etc.
*/
-_GLOBAL(cmd_line)
+ .globl cmd_line
+cmd_line:
.space 512
/*
@@ -1055,4 +1061,3 @@ _GLOBAL(cmd_line)
*/
abatron_pteptrs:
.space 8
-
^ permalink raw reply
* Re: Need help Understanding initial memory conditions.
From: David H. Lynch Jr @ 2005-10-19 5:16 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <435557A0.8090505@iki.fi>
Kalle Pokki wrote:
> David H. Lynch Jr. wrote:
>
>> Kalle Pokki wrote:
>>
>>> 1. Put RAM to 0x0000000 and flash to some location it mirrors to
>>> your boot vector. Linux always expects your physical memory to be at
>>> zero. It is then mapped to virtual address 0xC0000000.
>>
>>
>> In both this list and elsewhere I have seen several references to
>> the difficulty setting up Linux with a physical RAM base other than
>> 0x0. I was hoping that I could bypass that by re-arranging physical
>> memory using the BAT's or MMU.
>> I am gathering that while this is possible, that it not sufficient.
>> That if memory is re-arranged after power-on it has to be done by
>> something Linux is not aware of.
>
>
> I'm afraid you cannot fool Linux that way... it will take control of
> the BATs and MMU. Even as a concept, you cannot re-arrange physical
> memory with the MMU at all - it's virtual memory when you do the
> address translation. The only way to arrange physical memory is to
> program the memory controller. I don't know how flexible the OCM
> controller in ppc405 is, but I'd be surprised if one couldn't freely
> set the addresses to whatever suits best.
>
>
I have built a Kernel - that is something I am pretty compitent at.
My system is fairly similar to an abreviated xilinx ml-300, and I have
added it to the Linux configuration and made what adjustments I beleive
were needed (mostly eliminating hardware I do not have or want). The
resulting Kernel is configured and successfully built.
Alright I have RAM at physical 0x0 now. I throw a copy of a compressed
linux image into RAM (anywhere special ?) load the assorted registers
with the appropriate values, fill the board info struct., and just jump
to the start of the image and pray that load text starts coming out my
serial port ?
Once this sucker gets through the code in head_4xx.S I should be in
business, or atleast to a point where I can deal with whatever crops up.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox