2013/3/3 Jeremy Bennett <[email protected]>: > 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
Very nice work indeed. The readmemh ascii hex format would be nice for small/sparse memory contents, but a binary file is probably more efficient for most cases. I'm having similar thoughts in orpsocv3, so maybe we just need a small utility library (based on what's in orpsocv2) that can convert formats back and forth. Sorry about all the two or1ksim branches. You caught us in the middle of a large transition. What we really would like to have instead is two Jeremy Bennetts ;) -- Olof Kindgren ______________________________________________ ORSoC Website: www.orsoc.se Email: [email protected] ______________________________________________ FPGA, ASIC, DSP - embedded SoC design _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
