As I write to Martin ----> Programed that COG as --- Active Serial JTAG loader -- can function.
BUT then it need act as --- Activation device for FPGA to be possible to recognize of standard JTAG programing software.
..
But I agree with You on Dual die -- As that give re-programmability to Propeller core --- BUT still need some type of loader on Propeller die to function
Yes, you need some means to read the Serial ROM, but that is so small, it hardly is called ROM in the classic Code sense.
A simple state engine can do that.
I won't be satisfied until the Prop II can be programmed directly from one of these:
Guys, seriously, give it a rest! Let Chip finish this thing so we can enjoy the fruits of his labors and get on with arguing about what features the Prop III should have.
I won't be satisfied until the Prop II can be programmed directly from one of these:
Guys, seriously, give it a rest! Let Chip finish this thing so we can enjoy the fruits of his labors and get on with arguing about what features the Prop III should have.
Can be done with state machine BUT that ads more transistors to silicon.
BUT as Last port don't use all PIN's externally simple to hide it from PIN usage of Package and still have full control of it to reprogram by simple program loaded to Propeller.
One Question how much more that add in cost in $$$ to made that dual die Package.
EDIT:
ONLY problem with state machine will You have to Initial program that ROM.
Yes, you need some means to read the Serial ROM, but that is so small, it hardly is called ROM in the classic Code sense.
A simple state engine can do that.
What does this gain, over Top placed ROM ? I'm sure this Some-RAM-Some-Rom-Some-Ram will bite users...
Can the very top ($FFFFFFFF) read from ROM ? (due to wrapping ?)
Any external memory cannot seamlessly patch above chip SRAM, as it has physically different access ?
It means that RAM extends from nearly the bottom (after a little ROM) to all the way to the top, so it becomes easy to allocate nice big RAM blocks which extend all the way up. For example, a 64kB block could take $10000..$1FFFF, not something like $0F800..$1F7FF if we had to accommodate a top-of-memory ROM. The bottom of memory gets a little chunked up, in any case, because of program and variable space. By putting ROM at the bottom, too, all the chunkiness is kept at one end, keeping the top end clean.
Given the concerns of ram v rom size and place, I wonder if there could be 128k of ram, 2k of which resets to what would be the rom code. That way you only need 17 bits of address lines, while all of hub ram is still writeable.
It means that RAM extends from nearly the bottom (after a little ROM) to all the way to the top, so it becomes easy to allocate nice big RAM blocks which extend all the way up. For example, a 64kB block could take $10000..$1FFFF, not something like $0F800..$1F7FF if we had to accommodate a top-of-memory ROM.
One could specify, with ROM at end of RAM, given the repeating nature of 32 bit decode, that ROM is officially at $FFFFFFFF. And that all other appearances in the address space are undocumented and not to be used. Future proofed right there. ROM can be any size and never bump into RAM.
Alternatively, maybe starting at $800 so it's then after the immediate address range. Or at least $400 to give a decent space. But, from what I've read earlier, there is some emulation code that is faster working from address 0 so any ROM located in early addresses will bust those programs.
One could specify, with ROM at end of RAM, given the repeating nature of 32 bit decode, that ROM is officially at $FFFFFFFF. And that all other appearances in the address space are undocumented and not to be used. ROM can be any size and never bump into RAM. Future proofed right there.
Alternatively, maybe starting at $800 so it's then after the immediate address range. Or at least $400 to give a decent space. But, from what I've read earlier, there is some emulation code that is faster working from address 0 so any ROM located in early addresses will bust those programs.
ROM -- as much as needed for good function That are switched ACTIVE only in boot mode and load needed COG's. That give optimal use of RAM and as much space as needs to boot.
To that needs much extra work in Verilog code.
Sapieha, perhaps Chip haven't enough room for ram, rom and mux/tristate bus logic so masked ram is forced solution.
This has been mentioned, but not discussed much ... We're not talking about an SD card that's bootable on both a PC and a P2. We're talking about an SD card that boots a P2 and is readable / writable using a standard PC OS, whether Windows, Linux, or the MacOS. As such, it needs a standard FAT16 or FAT32 partition plus another partition for P2 bootstrap use. This 2nd partition can have any format needed for P2 boot use. We would need a utility program to either initialize an SD card with such a partition or add such a partition to an existing card, possibly by shrinking an existing partition like many such utilities on the market today. We should have a version of this program for the P1 and P2 as well as cross platform (Windows, Linux, MacOS). If necessary for booting, we could insist that the boot partition be the first on the volume or insist that the partition be close to the beginning of the volume as was necessary for some old BIOSes or insist that a boot partition not be an "extended partition".
Agree 100%. And if the dedicated partition is the first you can look directli in partition table for its partition type info (eg. 0x27 for security) and starting point. This I thing is the most code saving solution.
No consensus has been reached. I still think looking for a partition to boot from in the MBR is the best idea.
Well... I think their is a consensus that booting from the SD card should be available. I've been convinced that it can be done. I'm still concerned on how well it will work. I still remain disturbed by not being able to have universal compatibility for all MMC and SD cards in my driver after spending so much time trying to implement everything properly.
If you buy the spec from the SD association then the boot loader cannot be open source. So, it needs to be implemented with what we already have.
Anyway,
I am sure that raw read can fit in less than160 longs. Regarding ROM/RAM addressing no problems at all, I'll adapt to what will be done.
Regarding the SD specs:
Having PLC and Microsoft (from old DOS to Win) programming experience I am used to use non open source sw (all MS API, SDK, MFC libs are copyrighted by MS); I know that I can release my sw as open source even if it calls win api. I think that having a hidden low level routines, where only the calls are documented, to manage the SD in 4-bit mode, and so allowing for increased speed can be of common interest. I think that in this way no copyright is violated. Perhaps this is not achievable due to props cog/hub architecture but it will be nice.
It means that RAM extends from nearly the bottom (after a little ROM) to all the way to the top, so it becomes easy to allocate nice big RAM blocks which extend all the way up. For example, a 64kB block could take $10000..$1FFFF, not something like $0F800..$1F7FF if we had to accommodate a top-of-memory ROM. The bottom of memory gets a little chunked up, in any case, because of program and variable space. By putting ROM at the bottom, too, all the chunkiness is kept at one end, keeping the top end clean.
I'm not really following this ? Do you know exactly how much RAM finally fits ? is it a clean 128k, or might 140k, or 156k fit ?
The size of the RAM is set by silicon; which slice is ROM does not change a 64K access, and if you have a ROM long at one end, it can tell you where RAM is anyway. eg If the Memory size is 2^n, reading $ffffffff can give a ROM value.
If the Memory size is something else, not 2^n, then it's trickier to rely on wrap-reads.
The CPU does not really care about $1FFFF, or $1F7FF - it will load and compare any values you like.
I have used DEC and OR for loops on very small micros, as a means to make the fastest FIFO, upper memory bounded, (only works on one copy, and relies on wrap), but the Prop 2 is rather more powerful so should not need this level of fudging.
Is this type of code the reason you want to split the RAM ?
Mid ROM means you have two numbers for users and tools to track : LowerRAM Top, and Upper RAM bottom.
Top ROM means you have one number, just RAM-Top, and that can be ID'd in ROM if you want to make it revision safe.
I'm not really following this ? Do you know exactly how much RAM finally fits ? is it a clean 128k, or might 140k, or 156k fit ?
The size of the RAM is set by silicon; which slice is ROM does not change a 64K access, and if you have a ROM long at one end, it can tell you where RAM is anyway. eg If the Memory size is 2^n, reading $ffffffff can give a ROM value.
If the Memory size is something else, not 2^n, then it's trickier to rely on wrap-reads.
The CPU does not really care about $1FFFF, or $1F7FF - it will load and compare any values you like.
I have used DEC and OR for loops on very small micros, as a means to make the fastest FIFO, upper memory bounded, (only works on one copy, and relies on wrap), but the Prop 2 is rather more powerful so should not need this level of fudging.
Is this type of code the reason you want to split the RAM ?
The SPIN interpreter fills up the bottom of RAM with internal data and program code. The "stack", or more aptly "heap", grows up from there. The heap will end at $1FFFF and be contiguous to that point. He is saying that from a "programmer don't make dumb mistake and can't grok the addresses" he made the memory layout more friendly.
It's common to allocate chunks of SPIN heap without telling SPIN that you did that, so by making memory addresses programmer friendly, there is less possibility for error when allocating space manually.
The framebuffer is done this way in the video drivers, it takes the top of RAM and depends on the SPIN programmer to not grow the SPIN stack/heap up into framebuffer space and get corruption.
SPIN need rewrite for PROPELLER II -- to use CLUT as Stack -- That give no need for HUB usage to that and speed up it.
SPIN has STACK and HEAP. STACK is what you use for a stack based virtual machine, instead of registers.
HEAP is what you use for allocating chunks of memory. The distinction is fuzzy, but your reference to STACK is for calling stack frames, which is a different issue that what I explained. The SPIN stack isn't exactly the same as a stack in a language like C where you keep track of pointers.
The SPIN interpreter fills up the bottom of RAM with internal data and program code. The "stack", or more aptly "heap", grows up from there. The heap will end at $1FFFF and be contiguous to that point. He is saying that from a "programmer don't make dumb mistake and can't grok the addresses" he made the memory layout more friendly.
It's common to allocate chunks of SPIN heap without telling SPIN that you did that, so by making memory addresses programmer friendly, there is less possibility for error when allocating space manually.
The framebuffer is done this way in the video drivers, it takes the top of RAM and depends on the SPIN programmer to not grow the SPIN stack/heap up into framebuffer space and get corruption.
The framebuffer is done this way in the video drivers, it takes the top of RAM and depends on the SPIN programmer to not grow the SPIN stack/heap up into framebuffer space and get corruption.
I can understand the bottom-up and Top down allocates, what I am not seeing, is why having bit 12 of the Address, 1 instead of 0, buys you anything on a Prop 2 ?
You still need to avoid ROM, indeed, in the split-ram instance you need to avoid both edges of the ROM.
Mike Green did raise a good question yesterday on how to create the special SD card for booting...
You can do it with a Propeller, but how can you do it from a PC?
I spend a few minutes looking with Google and can't find any source code for low level SD card access...
I'm sure it's possible because there are a few SD card recovery tools and erasing tools out there...
But, they must have hacked the OS somehow to do it...
Mike Green did raise a good question yesterday on how to create the special SD card for booting...
You can do it with a Propeller, but how can you do it from a PC?
Repartitioning is totally unneeded. We're only talking prolly a 10kB file. But there will be a tool made that will, amongst other features, insert an image into a custom partition for those that desire it.
The how is not that hard, just use device level block read/write calls. It requires privileged access but not that big a deal. All the methods require at least some amount of raw block access to prep a SD card for booting.
Sapieha, perhaps Chip haven't enough room for ram, rom and mux/tristate bus logic so masked ram is forced solution.
It's more along the lines of "it is the way it is" - the layout is done. Chip has option only to convert some of the 128kB SRAM to ROM. So .... with more ROM there is less RAM.
I think it is simple that we imagine --- BUT I can't test it on every type SD as I don't have any to aware.
Only one I had to test it was very old 32MB uSD --- But look on picture.
If you use this formating program
https://www.sdcard.org/downloads/formatter_3/ ---- and have any SD cards to test on.
USE Option button and in it --- Format size adjustment.
On my uSD that option have made spare area that are 50 sectors + BOT sector = 51 sectors -- look on left side of picture --Partition 1 starting place
even on left side You will see -- in -- Sectors preceding Partition 1
Mike Green did raise a good question yesterday on how to create the special SD card for booting...
You can do it with a Propeller, but how can you do it from a PC?
I spend a few minutes looking with Google and can't find any source code for low level SD card access...
I'm sure it's possible because there are a few SD card recovery tools and erasing tools out there...
But, they must have hacked the OS somehow to do it...
USE Option button and in it --- Format size adjustment.
On my uSD that option have made spare area that are 50 sectors + BOT sector = 51 sectors -- look on left side of picture --Partition 1 starting place even on left side You will see -- in -- Sectors preceding Partition 1
Oh Sapieha! That's such a hack! Incidental deallocating is not a second partition.
We need only one that spare space for BOOT binary (that have in start signature and how long it is in bytes)
BUT we need test if it always start as sector "0" else how much sectors we need to add to be sure that we not disturb anything.
I see You don't read my posts that I have write before ---- SO
It is Rubbish
> IF You will bound that boot system to Be possible only use FAT and NO any other systems File system.
BUT if You will made LINUX else MAC else any other system that are not bound to Windows FAT system --- THEN You need rethink Yours thinking !!
Hmm, irrelevant gibberish is about all I can say to that. Wanting to have a second partition bares little relation to it being a necessity for supporting booting of the Prop2.
FAT is a perfectly useful universal, and simple, filesystem that pretty much everything can read and write. Propeller included. What's wrong with using a FAT volume/partition to boot from?
PS: I don't have any equipment running anything from M$. I use Wine for a few apps/games.
I think trying to read the FAT table from the SD card every time you boot would take up too much ROM space and take too much time...
Raw block mode would be more reliable, simpler and faster...
I think trying to read the FAT table from the SD card every time you boot would take up too much ROM space and take too much time...
Raw block mode would be more reliable, simpler and faster...
I think this perceived requirement to have SD booting as a feature in order to be accepted by engineers is unfounded. I think a few of you are projecting your own desires out to everyone.
Chip, I urge you to drop SD card booting of any kind. If you don't, then it's going to be no end of problems...
Comments
As I write to Martin ----> Programed that COG as --- Active Serial JTAG loader -- can function.
BUT then it need act as --- Activation device for FPGA to be possible to recognize of standard JTAG programing software.
Yes, you need some means to read the Serial ROM, but that is so small, it hardly is called ROM in the classic Code sense.
A simple state engine can do that.
Guys, seriously, give it a rest! Let Chip finish this thing so we can enjoy the fruits of his labors and get on with arguing about what features the Prop III should have.
-Phil
And after that re-design it for some $$$$$ to met markets expectations.
(The term "market expectations" is very significantly over used to justify preferences rather than material demand.)
Can be done with state machine BUT that ads more transistors to silicon.
BUT as Last port don't use all PIN's externally simple to hide it from PIN usage of Package and still have full control of it to reprogram by simple program loaded to Propeller.
One Question how much more that add in cost in $$$ to made that dual die Package.
EDIT:
ONLY problem with state machine will You have to Initial program that ROM.
It means that RAM extends from nearly the bottom (after a little ROM) to all the way to the top, so it becomes easy to allocate nice big RAM blocks which extend all the way up. For example, a 64kB block could take $10000..$1FFFF, not something like $0F800..$1F7FF if we had to accommodate a top-of-memory ROM. The bottom of memory gets a little chunked up, in any case, because of program and variable space. By putting ROM at the bottom, too, all the chunkiness is kept at one end, keeping the top end clean.
One could specify, with ROM at end of RAM, given the repeating nature of 32 bit decode, that ROM is officially at $FFFFFFFF. And that all other appearances in the address space are undocumented and not to be used. Future proofed right there.
Alternatively, maybe starting at $800 so it's then after the immediate address range. Or at least $400 to give a decent space. But, from what I've read earlier, there is some emulation code that is faster working from address 0 so any ROM located in early addresses will bust those programs.
That give non contiguous RAM addressing space and are bad idea -- If it need be in same addressing space --- Only end of it that are OK.
Sapieha, perhaps Chip haven't enough room for ram, rom and mux/tristate bus logic so masked ram is forced solution.
Agree 100%. And if the dedicated partition is the first you can look directli in partition table for its partition type info (eg. 0x27 for security) and starting point. This I thing is the most code saving solution.
I am sure that raw read can fit in less than160 longs. Regarding ROM/RAM addressing no problems at all, I'll adapt to what will be done.
Regarding the SD specs:
Having PLC and Microsoft (from old DOS to Win) programming experience I am used to use non open source sw (all MS API, SDK, MFC libs are copyrighted by MS); I know that I can release my sw as open source even if it calls win api. I think that having a hidden low level routines, where only the calls are documented, to manage the SD in 4-bit mode, and so allowing for increased speed can be of common interest. I think that in this way no copyright is violated. Perhaps this is not achievable due to props cog/hub architecture but it will be nice.
I'm not really following this ? Do you know exactly how much RAM finally fits ? is it a clean 128k, or might 140k, or 156k fit ?
The size of the RAM is set by silicon; which slice is ROM does not change a 64K access, and if you have a ROM long at one end, it can tell you where RAM is anyway. eg If the Memory size is 2^n, reading $ffffffff can give a ROM value.
If the Memory size is something else, not 2^n, then it's trickier to rely on wrap-reads.
The CPU does not really care about $1FFFF, or $1F7FF - it will load and compare any values you like.
I have used DEC and OR for loops on very small micros, as a means to make the fastest FIFO, upper memory bounded, (only works on one copy, and relies on wrap), but the Prop 2 is rather more powerful so should not need this level of fudging.
Is this type of code the reason you want to split the RAM ?
Mid ROM means you have two numbers for users and tools to track : LowerRAM Top, and Upper RAM bottom.
Top ROM means you have one number, just RAM-Top, and that can be ID'd in ROM if you want to make it revision safe.
That's a good idea, but it assumes the Memory is 2^N in size. Maybe that ( <> 2^N) is what Chip is getting at ?
The SPIN interpreter fills up the bottom of RAM with internal data and program code. The "stack", or more aptly "heap", grows up from there. The heap will end at $1FFFF and be contiguous to that point. He is saying that from a "programmer don't make dumb mistake and can't grok the addresses" he made the memory layout more friendly.
It's common to allocate chunks of SPIN heap without telling SPIN that you did that, so by making memory addresses programmer friendly, there is less possibility for error when allocating space manually.
The framebuffer is done this way in the video drivers, it takes the top of RAM and depends on the SPIN programmer to not grow the SPIN stack/heap up into framebuffer space and get corruption.
Why all talk in Old terms on SPIN.
SPIN need rewrite for PROPELLER II -- to use CLUT as Stack -- That give no need for HUB usage to that and speed up it.
SPIN has STACK and HEAP. STACK is what you use for a stack based virtual machine, instead of registers.
HEAP is what you use for allocating chunks of memory. The distinction is fuzzy, but your reference to STACK is for calling stack frames, which is a different issue that what I explained. The SPIN stack isn't exactly the same as a stack in a language like C where you keep track of pointers.
If You talk on "C" --- what is this ?
I can understand the bottom-up and Top down allocates, what I am not seeing, is why having bit 12 of the Address, 1 instead of 0, buys you anything on a Prop 2 ?
You still need to avoid ROM, indeed, in the split-ram instance you need to avoid both edges of the ROM.
You can do it with a Propeller, but how can you do it from a PC?
I spend a few minutes looking with Google and can't find any source code for low level SD card access...
I'm sure it's possible because there are a few SD card recovery tools and erasing tools out there...
But, they must have hacked the OS somehow to do it...
Repartitioning is totally unneeded. We're only talking prolly a 10kB file. But there will be a tool made that will, amongst other features, insert an image into a custom partition for those that desire it.
The how is not that hard, just use device level block read/write calls. It requires privileged access but not that big a deal. All the methods require at least some amount of raw block access to prep a SD card for booting.
It's more along the lines of "it is the way it is" - the layout is done. Chip has option only to convert some of the 128kB SRAM to ROM. So .... with more ROM there is less RAM.
I think it is simple that we imagine --- BUT I can't test it on every type SD as I don't have any to aware.
Only one I had to test it was very old 32MB uSD --- But look on picture.
If you use this formating program
https://www.sdcard.org/downloads/formatter_3/ ---- and have any SD cards to test on.
USE Option button and in it --- Format size adjustment.
On my uSD that option have made spare area that are 50 sectors + BOT sector = 51 sectors -- look on left side of picture --Partition 1 starting place
even on left side You will see -- in -- Sectors preceding Partition 1
Oh Sapieha! That's such a hack! Incidental deallocating is not a second partition.
We need only one that spare space for BOOT binary (that have in start signature and how long it is in bytes)
BUT we need test if it always start as sector "0" else how much sectors we need to add to be sure that we not disturb anything.
I see You don't read my posts that I have write before ---- SO
It is Rubbish
> IF You will bound that boot system to Be possible only use FAT and NO any other systems File system.
BUT if You will made LINUX else MAC else any other system that are not bound to Windows FAT system --- THEN You need rethink Yours thinking !!
FAT is a perfectly useful universal, and simple, filesystem that pretty much everything can read and write. Propeller included. What's wrong with using a FAT volume/partition to boot from?
PS: I don't have any equipment running anything from M$. I use Wine for a few apps/games.
Raw block mode would be more reliable, simpler and faster...
KISS Principle.
Get a pointer to a contiguous area from the MBR, boot from that.
This would also be file system agnostic, and NOT tied to FAT.
Not to mention it would take far less code...
It is also totally FAT compatible, just put a pointer to the boot cluster into the MBR.
Simple, efficient, takes little code, file system agnostic.
Trivial utility needed to "makeboot" for the prop.
Chip, I urge you to drop SD card booting of any kind. If you don't, then it's going to be no end of problems...