RE: [U-Boot-Users] current simple 8260 platform as start...
Actually this is bad advice. The *ADS boards have some special features which you will not find on any other board. Also, the implementation of the MPC8260ADS has some serious problems which have not been fixed for ages because the board is one of the many orphaned (i. e. not maintained) boards.
Like what? I'm interested because I've used the 8266ADS board as basis for our custom board. (Omitting some stuff like their PLA based boot config)
In message 9F5558593173D21190EA0008C7B17698C1E184@innsys1 you wrote:
Actually this is bad advice. The *ADS boards have some special features which you will not find on any other board. Also, the implementation of the MPC8260ADS has some serious problems which have not been fixed for ages because the board is one of the many orphaned (i. e. not maintained) boards.
Like what? I'm interested because I've used the 8266ADS board as basis for our custom board. (Omitting some stuff like their PLA based boot config)
Like the fact that CFG_DEFAULT_IMMR definition in MPC8260ADS.h will bring you nasty kernel crashes the first time you want to boot your Linux kernel.
Like the fact that there is seems to be need for a proprietary version of jffs2_part_info() (because of a broken flash layout?)
Etc.
The fact alone that the board is listed under "orphaned" should make you think.
Best regards,
Wolfgang Denk
Wolfgang Denk writes:
Wolfgang> Actually this is bad advice. The *ADS boards have some Wolfgang> special features which you will not find on any other Wolfgang> board. Also, the implementation of the MPC8260ADS has some Wolfgang> serious problems which have not been fixed for ages Wolfgang> because the board is one of the many orphaned (i. e. not Wolfgang> maintained) boards.
Rune> Like what? I'm interested because I've used the 8266ADS board Rune> as basis for our custom board. (Omitting some stuff like their Rune> PLA based boot config)
Wolfgang> Like the fact that CFG_DEFAULT_IMMR definition in Wolfgang> MPC8260ADS.h will bring you nasty kernel crashes the first Wolfgang> time you want to boot your Linux kernel.
CFG_DEFAULT_IMMR can't cause any crash. It only tells to U-Boot initialisation code where to find IMMR to change it to CFG_IMMR. CFG_IMMR was unusable, it's right (its value was copied from the board's manual just like the entire memory map), but it was fixed long time ago by my patches.
Wolfgang> Like the fact that there is seems to be need for a Wolfgang> proprietary version of jffs2_part_info() (because of a Wolfgang> broken flash layout?)
No, no, the flash is OK. At least, I think it's OK. I introduced JFFS2 support so I have to explain. The board provides two sources of HRCW: the FPGA (BCSR) and the flash. Many boards have got two flashes: small one for boot and large one for filesystem, etc. MPC826xADS/PQ2FADS has only one, and it's flash SIMM, so 8MB, 16MB, and 32MB flash can be supported by simple replacement of the SIMM. HRCW occupies only first bytes of the SIMM but since flash is erased by blocks, entire block (on 4x8bit SIMM it's 256KB) wasted. I prefer to use BCSR-supplied HRCW but didn't want to touch Motorola-provided value in the flash either. So I burn the U-Boot at 0xFFF00000 (8MB SIMM starts at 0xFF800000). In such a configuration, I have the range 0xFF840000-0xFFEFFFFF available for JFFS2. Standard jffs2_part_info() allows to specify first filesystem sector but not last. It "thinks" that the filesystem spans to the flash end. This is the reason why proprietary version of jffs2_part_info() appeared. Of course, different flash layout can be chosen.
Wolfgang> Etc.
Wolfgang> The fact alone that the board is listed under "orphaned" Wolfgang> should make you think.
In message 16302.24038.849399.138394@gargle.gargle.HOWL you wrote:
Wolfgang> Like the fact that CFG_DEFAULT_IMMR definition in Wolfgang> MPC8260ADS.h will bring you nasty kernel crashes the first Wolfgang> time you want to boot your Linux kernel.CFG_DEFAULT_IMMR can't cause any crash. It only tells to U-Boot initialisation code where to find IMMR to change it to CFG_IMMR. CFG_IMMR was unusable, it's right (its value was copied from the board's manual just like the entire memory map), but it was fixed long time ago by my patches.
You are right; sorry I confused this (I just remembered the _many_ emais I received about Linux crashing on the MPC8260ADS).
Wolfgang> Like the fact that there is seems to be need for a Wolfgang> proprietary version of jffs2_part_info() (because of a Wolfgang> broken flash layout?)No, no, the flash is OK. At least, I think it's OK. I introduced JFFS2 support so I have to explain. The board provides two sources of HRCW: the FPGA (BCSR) and the flash. Many boards have got two flashes: small one for boot and large one for filesystem, etc. MPC826xADS/PQ2FADS has
Actually in my experience these are only very few boards - less than 10%. Most use just "big" flash banks.
only one, and it's flash SIMM, so 8MB, 16MB, and 32MB flash can be supported by simple replacement of the SIMM. HRCW occupies only first bytes of the SIMM but since flash is erased by blocks, entire block (on 4x8bit SIMM it's 256KB) wasted. I prefer to use BCSR-supplied HRCW but didn't want to touch Motorola-provided value in the flash either. So I burn the U-Boot at 0xFFF00000 (8MB SIMM starts at 0xFF800000). In such a configuration, I have the range 0xFF840000-0xFFEFFFFF available for JFFS2. Standard jffs2_part_info() allows to specify first filesystem
But that wastes the whole last megabyte in flash, while U-boot easily fits in 256 kB. Such a fragmentation is IMHO worse.
sector but not last. It "thinks" that the filesystem spans to the flash end. This is the reason why proprietary version of jffs2_part_info() appeared. Of course, different flash layout can be chosen.
Well, as a summary my statement is still standing: the MPC8260ADS is not an "easy" board to start with. I do NOT recommend to use it as a model. YMMV.
Best regards,
Wolfgang Denk
Good evening (o;
Someone already working on a ssh box (sipo) port?
Just finished the jtag-0.5.1 port for it so the flash can initially be programmed (o;
rick
participants (4)
-
Richard Klingler -
Rune Torgersen -
Wolfgang Denk -
Yuli Barcohen