[U-Boot-Users] Protect Flash from tftpboot typos
Hi there!
I wonder if there is a solution possible to Protect the FLASH Chip from typos.
I have physikal Ram at 0x8000000 to 0x8FFFFFF and FLASH from 0x10000000 to 0x10FFFFFF. u-boot gets startet by the i.MX mechanism which maps the 1st MB of Flash to 0x0. The i.MX executes 1st command at 0x0 to 0xFFFFF
tftpboot should only put downloaded images to RAM. I had a customer recently who put 130.1.2.3 as the 1st argument to tftpboot and tftpboot tries to put the image to 0x130. I also do typos there and an 0x0 as 1st Argument destroys contents of Flash though it is protected! I think an linux kernel Image for example contains code sequences who unlock, erase and write flash succesfully.
I want to implement a mechanism which implements out of an config option a area where tftpboot acts (0x800000 to 0x8FFFFFF) and gives an error message otherway.
Is that possible and where is the entry point in the code to put the funtkionality to?
Regards, Konstantin Kletschke
In message 20040723102408.GB11790@synertronixx3 you wrote:
I wonder if there is a solution possible to Protect the FLASH Chip from typos.
No. I will not accept any submissions of an AI machine for U-Boot.
I have physikal Ram at 0x8000000 to 0x8FFFFFF and FLASH from 0x10000000 to 0x10FFFFFF.
...
tftpboot should only put downloaded images to RAM.
Indeed this is what it does. At least in the default configuration, i. e. if you don't enable options like CFG_DIRECT_FLASH_TFTP which are unsafe and officially deprecated.
I had a customer recently who put 130.1.2.3 as the 1st argument to tftpboot and tftpboot tries to put the image to 0x130.
U-Boot follows Unix design here:
"UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn
I also do typos there and an 0x0 as 1st Argument destroys contents of Flash though it is protected!
Seems you have configured U-Boot like that. On systems for which I am responsible attempts to TFTP to flash will not do harm.
I think an linux kernel Image for example contains code sequences who unlock, erase and write flash succesfully.
This may be, but a TFTP download will write to increasing addresses, while the programming sequence must be written to certain addresses which are (1) not contiguous and (2) which must be written in a special sequence. I don't think that TFTP (or a copy) to a memory region can accidentally trigger a flash programming sequence, unless the code explicitely attemts to program the flash (like TFTP with CFG_DIRECT_FLASH_TFTP option aenabled, or the "cp" command with a target address in flash memory).
I want to implement a mechanism which implements out of an config option a area where tftpboot acts (0x800000 to 0x8FFFFFF) and gives an error message otherway.
Such a feature is definitely not necessary. Don't waste your time. Instead, go and check what's going wrong on your system.
Best regards,
Wolfgang Denk
Am 2004-07-23 15:46 +0200 schrieb Wolfgang Denk:
i. e. if you don't enable options like CFG_DIRECT_FLASH_TFTP which
I do not find CFG_DIRECT_FLASH_TFTP mentioned anywhere in our include/configs/scb9328.h.
Is it included by
#define CONFIG_COMMANDS (CONFIG_CMD_DFL \ & ~CFG_CMD_LOADS \ & ~CFG_CMD_CONSOLE \ & ~CFG_CMD_AUTOSCRIPT \ | CFG_CMD_NET \ | CFG_CMD_PING \ | CFG_CMD_DHCP \ ) ?
Otherwise I don't know where else I could have this option enabled.
"UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn
Yeah, thats right. I have to protect our customers to fry their boards, not me :)
I also do typos there and an 0x0 as 1st Argument destroys contents of Flash though it is protected!
Seems you have configured U-Boot like that. On systems for which I am responsible attempts to TFTP to flash will not do harm.
tftp to flash does no harm. It is the mapped Area which is not protected by an default load adress when typos occur.
This may be, but a TFTP download will write to increasing addresses, while the programming sequence must be written to certain addresses which are (1) not contiguous and (2) which must be written in a special sequence. I don't think that TFTP (or a copy) to a memory region can accidentally trigger a flash programming sequence, unless the code explicitely attemts to program the flash (like TFTP with CFG_DIRECT_FLASH_TFTP option aenabled, or the "cp" command with a target address in flash memory).
Reading this I agree to you unlocking, erasing is not possible on increasing adresses. Otherwise IIRC I think the whole block can be unlocked and erased on different access adresses inside the block!
Otherwise how is it possible typos fry the flash device?
I am using intel 28F128J3...
I think I will replace tftpboot an cp commands for customers by two argument less firmware - linux kernel or rootfs - commands.
Konsti
On Friday 23 July 2004 10:37 am, Konstantin Kletschke wrote:
I think I will replace tftpboot an cp commands for customers by two argument less firmware - linux kernel or rootfs - commands.
Send the customer an autoscript file. That way they don't have to type any commands.
Kyle.
In message 20040723143731.GA10725@synertronixx3 you wrote:
I do not find CFG_DIRECT_FLASH_TFTP mentioned anywhere in our include/configs/scb9328.h.
-> ls -l include/configs/scb9328.h ls: include/configs/scb9328.h: No such file or directory
I cannot comment on code I've never seen.
Is it included by
...
Otherwise I don't know where else I could have this option enabled.
No, it is not.
Yeah, thats right. I have to protect our customers to fry their boards, not me :)
Just set up a service to recover these boards, and get rich ;-)
Seems you have configured U-Boot like that. On systems for which I am responsible attempts to TFTP to flash will not do harm.
tftp to flash does no harm. It is the mapped Area which is not protected by an default load adress when typos occur.
What is a "mapped area"?
Reading this I agree to you unlocking, erasing is not possible on increasing adresses. Otherwise IIRC I think the whole block can be unlocked and erased on different access adresses inside the block!
Otherwise how is it possible typos fry the flash device?
I am using intel 28F128J3...
Your flash driver does not drive the VPEN pin, it seems?
I think I will replace tftpboot an cp commands for customers by two argument less firmware - linux kernel or rootfs - commands.
I don't think this is a good idea. The software should behave as documented, and U-Boot documentation does not contain such arbitrary limits (nor do I like them).
Best regards,
Wolfgang Denk
Am 2004-07-23 17:13 +0200 schrieb Wolfgang Denk:
-> ls -l include/configs/scb9328.h ls: include/configs/scb9328.h: No such file or directory
I cannot comment on code I've never seen.
Yes, is not commited yet. Only wan't to know if the mentioned config snippets did not include the falsh tftp routines, thats all...
Just set up a service to recover these boards, and get rich ;-)
That is possible when this company has become big and richt like other global players :)
What is a "mapped area"?
the i.MX mirrors the first MegaByte of flash to 0x00000000 -> 0x000fffff
Your flash driver does not drive the VPEN pin, it seems?
No, it does not :(
Konsti
In message 20040726120408.GA23386@synertronixx3 you wrote:
Your flash driver does not drive the VPEN pin, it seems?
No, it does not :(
Well, it seems a solution for your problems has been found.
Best regards,
Wolfgang Denk
Am 2004-07-26 15:34 +0200 schrieb Wolfgang Denk:
Well, it seems a solution for your problems has been found.
I don't understand. If Flash driver drives VPEN Pin there also must be defined, where it should be driven and where not. So I could allow tftpboot in some areas and in some not also.
Regards, Konsti
In message 20040726150944.GA8491@synertronixx3 you wrote:
Well, it seems a solution for your problems has been found.
I don't understand. If Flash driver drives VPEN Pin there also must be defined, where it should be driven and where not. So I could allow tftpboot in some areas and in some not also.
Enable earing/programming only in the flash erase/program routines. Than any other code that really triggers a erase/program sequence will not do any harm.
This has nothing to do with tftp - it does not write to flash.
Best regards,
Wolfgang Denk
participants (4)
-
Konstantin Kletschke -
Konstantin Kletschke -
Kyle Harris -
Wolfgang Denk