Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 ROM code - Page 8 — Parallax Forums

Prop2 ROM code

1568101119

Comments

  • I don't see the problem with using a partition. Just a pointer requires the image to be contiguous which could be a problem with large images.
  • I think worrying about having the first stage booter able to boot from SD card is silly. It just doesn't matter. Second stage is a fine place for worrying about SD and all it's details.

    The only real upgrade to booting that could happen that would be significant is if they could get flash on die and not need an external flash chip, and that is unlikely to happen any time soon if at all.

    If you can't just copy a file to the SD card using stock OS stuff, and then boot from that on the P2, then it's not good enough, and most people won't use the feature.
  • Cluso99Cluso99 Posts: 18,066
    edited 2016-09-06 04:22
    I really don't know what all the fuss is about !!!

    Having a pointer in the MBR solves everything...

    No need for any old/current/new partition layout. Just works where ever you place your code sectors
    - just write that location to the MBR with whatever tool you wish to use, including a Prop program.

    If you want a separate Partition. No worries - you can do that too
    - just write that location to the MBR with whatever tool you wish to use, including a Prop program.

    If you want FAT16/FAT32 or any other XFS or whatever. No worries either - you can do that too
    - just write that location to the MBR with whatever tool you wish to use, including a Prop program.


    For me, I already use FAT32 for my PropOS and also ZiCog (Z80 & CPM2.2 emulation). I just copy the file(s) across to the FAT32 file system on my PC using either a USB SD Card Reader, a USB to microSD adapter, or an SD to microSD adapter - all exist and just work on my current W10 laptop, but they also work on my older XP, Vista, and W7 laptops (9 & 10 years old).
    I never change my boot code as it reads both FAT16 & FAT32 file systems and also CPM File Systems.
    All I need to support the new method is write the "pointers" to the MBR (using the Prop) and I can siplify my boot EEPROM Boot Program and it will work for now and in the future with whatever FATxx replaces FAT32.

    Everyone's method is covered by this simplification, so please, what is all the fuss about ???
  • Roy Eltham wrote: »
    I think worrying about having the first stage booter able to boot from SD card is silly. It just doesn't matter. Second stage is a fine place for worrying about SD and all it's details.

    The only real upgrade to booting that could happen that would be significant is if they could get flash on die and not need an external flash chip, and that is unlikely to happen any time soon if at all.

    If you can't just copy a file to the SD card using stock OS stuff, and then boot from that on the P2, then it's not good enough, and most people won't use the feature.
    I don't see why that should put people off. They already use a custom tool for loading programs over a serial connection. Why not use a custom tool to create bootable SD cards?

  • Cluso99Cluso99 Posts: 18,066
    Roy,
    Why require a FLASH chip just to boot from an SD Card ?

    If an SD Card is present then the FLASH pins can be used.

    All my current P1 boards require an EEPROM just to boot from an SD Card. I pre-program the EEPROM and disable writing to it. It's a waste of space and parts and for those who don't understand production, the cost of placing these components is far greater than the parts cost!!!
  • Cluso99Cluso99 Posts: 18,066
    edited 2016-09-06 06:44
    Sometimes I have to wonder whether you guys that are commenting have ever manufactured products in volume and/or needed to be price competitive ???
    I have designed and manufactured price competitive products in the 100,000's per annum (including for Apple USA). I have also co-owned and run a contract assembly house.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-09-06 07:14
    If you load your firmware onto an SD card and insert it into a P2 system you could then download a binary serially into RAM for setting up the MBR automatically. A single one step process, no PC code involved. On the next reset it will boot your file nicely from the microSD. No Flash chip required!
  • I wonder how many commercial or high volume projects using a Prop also have and SD card at all let alone one for booting from?
    Probably the same is true for most MCUs.

    I was a bit harsh saying it was silly, but I don't think it's going to really impact things much if P2 can't 1st stage boot from SD. Yes I am aware of the extra costs involved, but that's only for people that want the SD boot option without having a flash chip, and like I said before, it's probably not much of the lifetime volume of P2s.

    I also think you are overstating the "simplicity" of making some ROM code that will reliably read and boot from any SD cards past, present, and future.
  • Rayman wrote: »
    Well, it seems there are a lot of different opinions about how to handle SD boot.
    Maybe that's another reason to leave that to a second stage booter...
    Roy Eltham wrote: »
    I think worrying about having the first stage booter able to boot from SD card is silly. It just doesn't matter. Second stage is a fine place for worrying about SD and all it's details.

    The only real upgrade to booting that could happen that would be significant is if they could get flash on die and not need an external flash chip, and that is unlikely to happen any time soon if at all.
    This means that SD users will always have to use also a flash chip.
    Roy Eltham wrote: »
    If you can't just copy a file to the SD card using stock OS stuff, and then boot from that on the P2, then it's not good enough, and most people won't use the feature.
    Anyone who deal/program any mcu is using a sort of non OS stock utility/environment/IDE. Any non OS stock utility that allows you to transfer the firmware on the SD will be used by these users with no pain. Eventually it can be called from the IDE itself and thus become transparent to the developer.


  • David Betz wrote: »
    I don't see the problem with using a partition. Just a pointer requires the image to be contiguous which could be a problem with large images.
    Being contiguous could be an issue only under file system. With raw block access this is not a problem, at any size.

  • dMajo wrote: »
    David Betz wrote: »
    I don't see the problem with using a partition. Just a pointer requires the image to be contiguous which could be a problem with large images.
    Being contiguous could be an issue only under file system. With raw block access this is not a problem, at any size.
    dMajo wrote: »
    David Betz wrote: »
    I don't see the problem with using a partition. Just a pointer requires the image to be contiguous which could be a problem with large images.
    Being contiguous could be an issue only under file system. With raw block access this is not a problem, at any size.
    That's exactly my point. Use a separate partition and a big contiguous image is not a problem.

  • dMajodMajo Posts: 855
    edited 2016-09-06 14:03
    Cluso99 wrote: »
    I really don't know what all the fuss is about !!!

    Having a pointer in the MBR solves everything...
    ...
    Agreed.

    Could we define the pointer location being a little-endian long (4 bytes) at absolute address 1F6h (502 dec) of SD's block 0.
    Could we define an ID byte being at abbsolute address 1F2h (498 dec) with a defined value from one of this: B0h, A2h, 12h, 27h
    ** Could we optionally define absolute address 1EEh (494dec) as fw image pointer (for multi image cases, safe filed fw upgrades).

    Could we define the following SD boot process:
    1) read block 0 form SD
    2) evaluate if its 1F2h address contains B0h value
    3) start sequentially reading reading blocks from the one pointed by address 1F6h
    3**) with image pointer: start sequentially reading blocks from the one pointed by: value(1F6h)+(value(1EEh)*4096)
    4) first fw image data will contain the size to read.

    And in all this I purposely never used any definition like MBR, partition, file, file-system, ...
    Anyone is free tho call the above locations/process however he wants.

    Cluso99 wrote: »
    ...Everyone's method is covered by this (the above) simplification ...

    And with optional image pointer you can also safely field upgrade the firmware (one image) and at the end change the image pointer to it.
    As I said before there will be some users that will use an SD in place of the flash chip even without any filesystem and never remove it from the board.
    Peter seems to be one of them
    ...
    I envisage using microSD cards simply as local storage with its own secure and Flash friendly file system without ever being removed or placed into a PC. The initial boot image burner and image would be loaded via serial.
    ...

    Edit:
    PS: I know that multiimage boots can be handled from the second stage loader but, if the fw image at the beginning contains its size and execution address and mode(hub/cog exec), also the first stage can load all the hub ram using both flash or SD. Why bother with multistage loaders when not required.
  • dMajo wrote: »
    Cluso99 wrote: »
    I really don't know what all the fuss is about !!!

    Having a pointer in the MBR solves everything...
    ...
    Agreed.
    When you say "pointer in the MBR" do you mean an entry in the partition table? If not, where in the MBR do you propose to put the pointer?

  • Who said that there is no dd for windows?

    dd for windows: http://www.chrysocome.net/dd

    Tutorial : http://www.86duino.com/?p=11264
  • Ramon wrote: »

    This tutorial says that you need a SD-USB adapter. But actually there is no need for such adapter. Every laptop with integrated SD reader can recognize the disk. But the tutorial is still useful.

  • Cluso99Cluso99 Posts: 18,066
    Roy Eltham wrote: »
    I wonder how many commercial or high volume projects using a Prop also have and SD card at all let alone one for booting from?
    Probably the same is true for most MCUs.
    ...
    I have commercial P1 products that only contain a simple boot code to boot from the SD card. The EEPROM has write protect enabled.

    I also have hobbyist P1 boards that also only use the EEPROM to boot from SD card. Again the EEPROM is write protected by default.

    Another point here is that these cards DO NOT REQUIRE AN EXPENSIVE PROPPLUG TO WORK. Not even a cheap ($1.50) USB-Serial board is required to change the code on the SD card.
    ...
    I also think you are overstating the "simplicity" of making some ROM code that will reliably read and boot from any SD cards past, present, and future.
    IMHO I have proven it works since my boot code has worked for about 7 years so far and I haven't used the simpler method which removes the FAT16/32 requirement, which BTW I suggested many years ago for the P2.
  • Cluso99Cluso99 Posts: 18,066
    I am proposing the use of the last 16 bytes of the boot code section of the MBR. This is at offset $1AE in Sector 0.
  • Cluso99 wrote: »
    I am proposing the use of the last 16 bytes of the boot code section of the MBR. This is at offset $1AE in Sector 0.
    According to Wikipedia that is a partition table entry:

    https://en.wikipedia.org/wiki/Master_boot_record
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-09-06 15:33
    This is how I have my P2 boot set up but I am open to suggestions as to how we do the signature and offset etc.
    TF2# 0 $200 SD DUMP
    00.0000: 50 32 42 4F 4F 54 20 20 49 4D 47 20 00 64 49 6C    P2BOOT  IMG .dIl
    00.0010: 79 48 79 48 00 00 E6 73 58 44 CC 02 00 00 10 00    yHyH...sXD......
    00.0020: 80 F2 00 00 00 00 02 00 2A 00 04 00 00 00 00 00    ........*.......
    00.0030: 26 E6 01 00 C0 73 02 00 00 00 00 00 00 00 00 00    &....s..........
    00.0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    < snip - all zeros >
    00.01A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    00.01B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02    ................
    00.01C0: 03 01 0B 6D ED E6 00 20 00 00 00 C8 7A 00 00 00    ...m... ....z...
    00.01D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    00.01E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    00.01F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA    ..............U. ok
    TF2# $1BE $40 SD DUMP
    00.01BE: 00 02 03 01 0B 6D ED E6 00 20 00 00 00 C8 7A 00    .....m... ....z.
    00.01CE: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    00.01DE: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    00.01EE: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................ ok
    TF2#
    

    The image sector pointer is at offset $20:
    TF2# $20 X@ .LONG 0000.F280 ok
    TF2# $F280 SECTOR  ok
    TF2# SDBUF $80 DUMPL
    00.F200: FCEC.1FA4 FCEC.1DA4 FCEC.1BA4 FCEC.19A4    ................
    00.F210: FCEC.17A4 FCEC.15A4 FCEC.13A4 FCEC.11A4    ................
    00.F220: FCEC.0FA4 FCEC.0DA4 FCEC.0BA4 FCEC.09A4    ................
    00.F230: FCEC.07A4 FCEC.05A4 FCEC.0240 FCEC.01A4    ........@.......
    00.F240: FD65.7E20 F600.4E24 F184.4E02 F604.4C00     ~e.$N...N...L..
    00.F250: FC50.4C27 F600.5027 F184.5004 FC60.4C28    'LP.'P...P..(L`.
    00.F260: FF80.0001 FC8B.8024 FF00.0078 F604.4200    ....$...x....B..
    00.F270: F604.4C00 FD60.0824 FD60.2824 FD60.4428    .L..$.`.$(`.(D`. ok
    TF2#
    
  • RaymanRayman Posts: 13,797
    Seems we've had this sd boot debate several times in the past...
    I'm still with Roy, that a normally formatted SD card with a specific filename to boot from is the simplest approach. That's what the code I posted does.
    This is also how most other devices with SD storage, work. Just with files, not MBR or partition tricks...
    I also expect there to be other resources on the SD card besides just the boot code, BTW.

    Being able to program the P2 without a PropPlug does sound good.
    Maybe that's the only reason to think about having SD read in ROM.
    On the other hand, P2 can be USB device or host, allowing one to program directly that way...


  • Rayman wrote: »
    Seems we've had this sd boot debate several times in the past...
    I'm still with Roy, that a normally formatted SD card with a specific filename to boot from is the simplest approach. That's what the code I posted does.
    This is also how most other devices with SD storage, work. Just with files, not MBR or partition tricks...
    I also expect there to be other resources on the SD card besides just the boot code, BTW.

    Being able to program the P2 without a PropPlug does sound good.
    Maybe that's the only reason to think about having SD read in ROM.
    On the other hand, P2 can be USB device or host, allowing one to program directly that way...

    Doesn't that mean the ROM needs to understand the filesystem format? I really don't like the "search for a magic string" approach and the requirement that the file be contiguous.

  • RaymanRayman Posts: 13,797
    The FAT filesystem format is quite simple actually... The code I posted uses the FAT, so the file doesn't have to be contiguous.
  • rjo__rjo__ Posts: 2,114
    Right now...with the P2v, hub ram, which is not specifically re-written, is conserved between hot reboots.
    Is this going to be true for the P2 chip?
  • Rayman wrote: »
    The FAT filesystem format is quite simple actually... The code I posted uses the FAT, so the file doesn't have to be contiguous.
    I would prefer that the ROM not know anything about FAT.
  • rjo__rjo__ Posts: 2,114
    David Betz wrote: »
    Rayman wrote: »
    The FAT filesystem format is quite simple actually... The code I posted uses the FAT, so the file doesn't have to be contiguous.
    I would prefer that the ROM not know anything about FAT.

    +1


    I think "Net" booting is very important, but I have no idea about the timing constraints. Somewhere in there we might need a bit that says the boot code is coming from a wireless serial connection... wait a little longer than normal. It could be a switch... we certainly have enough pins:)



  • Won't the plain text serial option cover that case?
  • I read a little bit about it and windows is able to access RAW disks.

    After WinXP the disk has to be locked or un-mounted to do so.

    You can then use the standard file operations on the RAW disk using a name like "\\.\PhysicalDrive2" or even "\\.\H:" for a volume on a partition.
    #include <io.h>
    #include <stdio.h>
    #include <stdlib.h>
    
    int main()
    {
    	int fd;
    	int result;
    	unsigned char buf[512];
    	fd = open("\\\\.\\PhysicalDrive1",0);
    	if (fd == -1)
    	{
    		printf("%d Open \n", fd);
    		return -2;
    	}
    	result = read(fd, buf, 512);
    	printf ("%d Read \n", buf[511]);
    	return buf[511];
    }
    

    read access usually does not need un-mounting and mounting (or locking/unlocking), but write access does.

    But I still think the most easy way would be a program to load into RAM of the chip to do the writing.

    Enjoy!

    Mike
  • cgraceycgracey Posts: 14,133
    I've been busy getting PNut.exe adapted to the new serial text loading scheme.

    I haven't taken any time yet to read how SD works, so I don't have my own opinion of what should be done. If I had a flow chart or pseudo code to go from, I could write the code. I agree there's no room for FAT. We need a simple approach without many layers of decisions. I wish you guys could come to some agreement, given my own current lack of understanding.

    How about this: What can be achieved in 64 instructions? In 128? In 256?
  • rjo__rjo__ Posts: 2,114
    potatohead wrote: »
    Won't the plain text serial option cover that case?

    I really don't know, but then again it is not exactly a critical point either:)

    My question about hub ram is germane to the issue of speed. If hub ram is conserved while power is on, then if someone wants the fastest possible reboot... It seems to me that RAM would be the place for emergency code, not pushing speed in the ROM process.
  • cgraceycgracey Posts: 14,133
    ...And, I'm really glad you guys are concerned about this. Being able to boot from an SD card would be really clean. Hello, stand-alone bench computer!
Sign In or Register to comment.