quick boot to other module

Moderators: lily.li, violet, jeremy882, crail.lyu969

tormod
Elementary-2
Elementary-2
Posts: 271
Joined: Mon Oct 18, 2010 1:18 am

Re: quick boot to other module

Post by tormod » Tue Jan 22, 2013 4:48 am

JackTheVendicator wrote:Anyway, I'm still considering if it's a good idea to add some code to reset peripherals before jumping to another APP.
Did you read my comments above on executing the new application? (I have now added section headers to that post - I realize people don't read through such a long post :P )

gabonator1
Kindergarten
Kindergarten
Posts: 85
Joined: Thu Sep 15, 2011 7:54 pm
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: dso quad
Location: Sered, Slovakia

Re: quick boot to other module

Post by gabonator1 » Tue Jan 22, 2013 5:30 am

Sorry guys :)

Yes Tormod, I was. Buit I decided to work on other stuff and then suddenly Jack sent me few emails with the exact code :) I was very curious and gave it a try and it worked, so I was very happy and wanted to share this success :)
As next step I would like to make a PAWN application that does the same (resets to APP1), but unfortunatelly JPA does not have API functions for this purpose...

gabonator1
Kindergarten
Kindergarten
Posts: 85
Joined: Thu Sep 15, 2011 7:54 pm
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: dso quad
Location: Sered, Slovakia

Re: quick boot to other module

Post by gabonator1 » Sat Feb 02, 2013 11:28 pm

I have an idea... Instead of having 4 application slots and using DFU for loading them into flash, I was thinking about applications that would be stored on the EEPROM (2MB disk). All these application would be ELF files compiled to occupy ROM area corresponding to slots 2..4 (large projects cannot fit into single slot) with entry point on slot2.
The main application would have something like file manager, where you can list all applications and execute any of them. File manager would act as a DFU and after selecting some application, it would read the ELF file and burn it into flash. The documentation of STM32 processor says, the flash should survive more than 10000 overwrites. Before burning the image it can check whether the image is not already there to prevent useless overwrites. 2MB is not a lot of space, but I think the internal storage could handle about 20 applications including some user data. To save space I decided to use binary ELF file instead of HEX. For example - my firmware hex file is 471000 bytes long, stripped ELF takes 277000 bytes, more stripped ELF takes 167817 bytes, but keep in mind that this firmware is quite complex. Normal application will be about 30kB.

Other benefits: we can support also HEX files, so any applications that were already made for DSO could be loaded without any problem (except the images compiled to occupy first slot), burning new images without restarting the DSO - you just copy new file on disk and DSO would ask the user whether he wants to execute it. The user do not need to know that there is any DFU utility

Prerequisites: findfirst/findnext listing functions - JPA already ported some more reliable FAT functions, so directory listing functionality should be already there, DFU source code - I am looking for the DFU code to see how does the HEX file is being burnt onto flash... Can anybody help?

jpa
Elementary-2
Elementary-2
Posts: 215
Joined: Wed Nov 02, 2011 4:06 am
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: DSO Quad

Re: quick boot to other module

Post by jpa » Sun Feb 03, 2013 12:44 am

gabonator1 wrote: To save space I decided to use binary ELF file instead of HEX. For example - my firmware hex file is 471000 bytes long, stripped ELF takes 277000 bytes, more stripped ELF takes 167817 bytes, but keep in mind that this firmware is quite complex. Normal application will be about 30kB.
Why not just .bin? It's much easier to parse than .elf (actually no need to parse at all, just write it to some hardcoded address).
gabonator1 wrote: Prerequisites: findfirst/findnext listing functions - JPA already ported some more reliable FAT functions, so directory listing functionality should be already there
It is.

Another way to do this all would be to reserve some area in the extra flash for "loadable applications". That way it wouldn't conflict with any old apps, and also if you run out of write cycles it doesn't matter that much because it's only the extra flash anyway.

I like this idea much more than the basic "switch quickly between apps", which is a bit useless IMO. I think alterbios could be a good place for code like this. I'm already planning to add FPGA loading functions to alterbios, so this would be similar:

bool load_app(const char *filename, void *address);
void start_app(void *address);

(But I'm not planning to spend much time on DSO Quad in the near future, so this is just random babble.)

gabonator1
Kindergarten
Kindergarten
Posts: 85
Joined: Thu Sep 15, 2011 7:54 pm
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: dso quad
Location: Sered, Slovakia

Re: quick boot to other module

Post by gabonator1 » Sun Feb 03, 2013 5:38 pm

Bin has not any information where to load it, it is just an image of whole ROM. Second problem is that it contains large segments filled with zeros, without compression they are unreasonably big and you can't identify unused parts which do not require to flash.

ELF format defines which part of elf file should be loaded into ROM/RAM at specific address. Actually it is very simple to parse it, it has its own header defining how many program headers and section headers continue after the main header. Program header defines the memory address where a block of data should be loaded with offset and size of the data block inside the elf file. Section header is something we do not care about, I made a utility that removes all the section headers and all unreferenced data from ELF file to make is small as possible. By this stripping approach I was able to reduce the size from 379kb (277kB after gcc-strip that removes all debug informations) to 167kB (in the stripped file there were still large zeroed parts and some compiler extra informations + section names).

Here is a read-elf report:

Code: Select all

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x804c000
  Start of program headers:          52 (bytes into file)
  Start of section headers:          0 (bytes into file)
  Flags:                             0x5000002, has entry point, Version5 EABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         3
  Size of section headers:           40 (bytes)
  Number of section headers:         0
  Section header string table index: 11 <corrupt: out of range>

There are no sections in this file.

There are no sections in this file.

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000094 0x0800c000 0x0800c000 0x00171 0x00171 R   0x8000
  LOAD           0x000205 0x0804c000 0x0804c000 0x28ae8 0x28ae8 RWE 0x8000
  LOAD           0x028ced 0x20003000 0x08074ae8 0x0029c 0x083e8 RW  0x8000

There is no dynamic section in this file.

There are no relocations in this file.

No version information found in this file.

I understand you, that was pretty nasty from seeedstudio to close the competition in this way. Actually I don't fully understand whether the competition is over or the remaining prices are waiting for assignment...

Jerson
Kindergarten
Kindergarten
Posts: 66
Joined: Fri Sep 23, 2011 7:09 pm
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: dso Nano, dso nano quad
Location: Bombay, INDIA
Contact:

Re: quick boot to other module

Post by Jerson » Sun Feb 03, 2013 7:57 pm

that was pretty nasty from seeedstudio to close the competition in this way. Actually I don't fully understand whether the competition is over or the remaining prices are waiting for assignment...
From what I saw on the blog, there was only the gold prize that was announced; the others are for a 'next time'. I am surprised that there were no entries from their side to even lay claim to the other prizes. That indirectly means they might want the rights to the gabo IP.

c.wilt
Pre-kindergarten
Pre-kindergarten
Posts: 27
Joined: Thu Jul 19, 2012 9:05 pm
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: DSO Quad

Re: quick boot to other module

Post by c.wilt » Mon Feb 04, 2013 12:01 am

I did not like the way Seeed has handled this contest. Gabonator1, congrats on the win. I enjoy your UI design and I hope you continue to develop it. Hopefully Seeed does not claim it as theirs.

JPA, I enjoy your work a great deal as well. Please don't stop development because of this. I am still planning write capacitance and inductance meters in pawn.

gabonator1
Kindergarten
Kindergarten
Posts: 85
Joined: Thu Sep 15, 2011 7:54 pm
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: dso quad
Location: Sered, Slovakia

Re: quick boot to other module

Post by gabonator1 » Tue Feb 05, 2013 3:36 am

I have only found the DS201 (dso mini) DFU utility code. It is the last RAR archive on this page (DS0201_OpenSource.rar) http://code.google.com/p/dsonano/downloads/list, I would like to know the reason why the quad's DFU utility source code is not published yet.

Post Reply