On Wed, 2013-02-27 at 12:58 -0700, Jack Thomasson wrote: > i am using or1k-elf (newlib) and needed a way to inject lots of data into > or1ksim for regression tests. on real but simple hardware i could program a > flash memory from a file and test against it many times until my code passes. > so i figured to emulate this behavior by providing another initialization > method for memory blocks. the configuration syntax is simple: > > section memory > type = file > name = "/tmp/FLASH" > mc = 0 > ce = 3 > baseaddr = 0xe0000000 > size = 0x00400000 /* 4 MB */ > delayr = 1 > delayw = -1 > end > > enjoy the patch attached.
Hi Jack, Nice work. Could I get you to make two other changes, and then I'll merge it into the mainline. 1. Could you update the documentation (in the doc folder) to match. 2. Could you supply a git patch if at all possible. The main repo is at https://github.com/openrisc/or1ksim. Note that there are now two branches of Or1ksim, to deal with the new style OpenRISC architecture naming (targets called or1k-* rather than or32-*). Could you check if this affects you code (I'm not sure if the constant OR32_BIG_ENDIAN becomes OR1K_BIG_ENDIAN for example). If it does, I'll ideally need two patches, one for each branch (sigh). One day the problem will go away, when we can drop the or32 branch. I have some questions/commentary on your code. You don't need to do anything about these - it's just to help my understanding. 1. peripheral/memory.c: I'm curious about the use of "seed" for the file handle name. Personally I'd have defined a variable "fh" (or similar) to avoid confusion. 2. peripheral/memory.c: I'm not sure worrying about endianness is a good thing here. I would be inclined to say that the file is just a byte image, and it is up to the user to ensure the sequence of bytes matches the endianness of the machine. It will mean the file can always be used for other tools as a true image of memory for the particular machine. It is trivial for a user to have an external utility to swap byte order to create a new file if that is what they need. 3. Is a straight binary file what you want? Had you considered supporting the image formats used by Verilog $readmemh and $readmemb. Maybe these should be further memory options, "readmemh" and "readmemb" for the future. Thanks for the contribution. Jeremy Or1ksim maintainer BTW - there are two OpenRISC mailing lists, and by convention we cross-post to both, as I have done with this reply. You don't want to ask why... (sigh). J -- Tel: +44 (1590) 610184 Cell: +44 (7970) 676050 SkypeID: jeremybennett Email: [email protected] Web: www.embecosm.com _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
