Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

a new way to avoid remove/insert SD card again and again #25

Open
zhangboyang opened this issue Oct 28, 2016 · 22 comments
Open

a new way to avoid remove/insert SD card again and again #25

zhangboyang opened this issue Oct 28, 2016 · 22 comments

Comments

@zhangboyang
Copy link

zhangboyang commented Oct 28, 2016

Recent firmware support network booting on pi2 (but not pi1), so we can setup a dhcp/tftp server, let the pi2 fetch kernel7.img from our server and then boot it.
I think it is easier to setup and do not require some special hardware.

this is my configuration:
connecting

screenshot:
screenshot

@Piping
Copy link

Piping commented Oct 5, 2017

Hi, can you talk a bit more on how to setup the Ethernet and IP for the client?

So in bare metal environment what is required steps to achieve this?

@ghost
Copy link

ghost commented Oct 5, 2017

Why not go all the way and just SSH in instead of UART? The binary would be a bit big, but then you'd be able to do everything with 2 wires and have the flexibility to transfer large files.

@Piping
Copy link

Piping commented Oct 5, 2017

@KNNSpeed Hi, this is bare metal programming and SSH is just not there.

@ghost
Copy link

ghost commented Oct 5, 2017

@Piping I know, I'm saying it could be implemented at the cost of a rather large binary (and yes, it--or something reasonably similar in functionality--can most definitely be done)

@Piping
Copy link

Piping commented Oct 5, 2017

@KNNSpeed this is a problem like chicken and eggs. Anyway, I am just looking for Ethernet solution relies on the bootcode.bin that is provided by the pi.

UART + boot loader to load program solution should be fine too, although I cannot get the code in this repo to work with pi3 B +.

@ghost
Copy link

ghost commented Oct 5, 2017

I have working uart bootloader code somewhere for a Pi 3 B+. Let me see if I can find it.

@ghost
Copy link

ghost commented Oct 5, 2017

Here you go. I haven't used this in a while, but on a Pi 3 I was able to transfer files over UART and press "g" to run them, no SD card swapping needed. Included is a little text file with the command line syntax to transfer stuff over terminal (for Mac, but linux isn't all that different).

UART_Raspi3_Bootloader.zip

@Piping
Copy link

Piping commented Oct 5, 2017

@KNNSpeed This is great! I appreciate that!!!

@Piping
Copy link

Piping commented Oct 5, 2017

@KNNSpeed so correct me if I am wrong, dwelch67's bootloader load the code at 0x8000 position right? the bootloader itself resides in the 0x0 for pi3?

@ghost
Copy link

ghost commented Oct 5, 2017

I... can't remember. It's been like a year and I didn't write it down... Hopefully I used the 64-bit stuff. You could send a program that just prints its memory address and find out (I'd like to know, too).

@ghost
Copy link

ghost commented Oct 5, 2017

Well, I also found these compiled kernel IMGs.

Bootloader07 from aarch64:
bootloader07_64bit.zip

Bootloader07 from the root of this repo:
bootloader07.zip

I don't remember if these actually work, though; like I said it's been a while... Some combination of these do work, since I was able to use UART over GPIO to load some test programs (like I used UART to load one of the blinker programs and print "hello world"). Unfortunately I neither have the UART cable or a bare Pi 3 at the moment to check all this myself. :/

@bluecereal
Copy link

@Piping check out the memmaps in some of the examples. like this and this.

@bluecereal
Copy link

bluecereal commented Oct 6, 2017

also this anddddd also also this:

I normally set my stack pointer to be at the top of some bank of ram
if only one ram bank in the system then the top of that ram bank. See
the top level README, they force us to start somewhere other than zero
so for such simple programs like these I am setting the program to start
at 0x8000 and the stack to start at 0x7FFC. Note that on an ARM the
stack pointer (r13) points at the first address after the top of the
stack so setting r13 to 0x8000 means the stack starts at 0x7FFC and
works down away from our program.

basically yes dwelch67's bootloader usually loads the code at 0x8000, but you can set the bootloader to load code at any memory address you like.

@ghost
Copy link

ghost commented Oct 6, 2017

@Piping Looks like the simple answer to your question in its entirety is yes.

Thanks @bluecereal!

@Piping
Copy link

Piping commented Oct 7, 2017

@bluecereal @KNNSpeed Thanks for your reply.

I am testing with the aarch64 code inside the board/pi3/aarch64.

I set up my config file with kernel_old=1 and other settings in @dwelch67 's repo.

The bootloader07 can print 12345678 and ihex string as expected. Although the bootloader does not load program correctly with cu, while minicom is just too hard to learn to use.

I use the following command if anyone interest.

sudo cu -s 115200 -l /dev/cu.usbserial
and use type ~> to send a file. But it only prints 1 R R R R timeout error. I am not sure what is going here. I used serial cable from uart to ttl with a chip called PL2303.

I also used the toolchains from linaro, aarch64-elf-gcc for example.

@timanu90
Copy link

timanu90 commented Oct 7, 2017

For terminal, I like to use GTKTERM is very simple. To send a file just go file->send raw file select your gcc generated file in format ihex and done. Works great give it a try.

@ghost
Copy link

ghost commented Oct 8, 2017

In the first zip file I provided the exact command line to use for picocom, which is a pretty simple program. I agree minicom is pretty tough to use. If you do what I wrote in the text file, you just specify the file path (you can drag 'n' drop to copy the path depending on your OS), hit enter, and it sends the file. Once the file is sent, IIRC you just press "g" and it runs your new thing. I might also have a version that auto-runs the sent file without waiting for the "g" key to be pressed somewhere.

I think the only difference between Mac using MacPorts and linux is that on linux /dev/tty.usberserial is actually /dev/tty[somethingelse].

@Piping
Copy link

Piping commented Oct 8, 2017

@KNNSpeed Thanks again. I install the picocom using brew. And it works great!!

Another problem is then after uart02 program loaded into the system, it pints number, but it could not echo back what I typed. Is there any special control I need to input before send character to PI3 side?

@timanu90 Hi, I am on a mac computer and picocom is just easier to get. Thanks anyway!

@Piping
Copy link

Piping commented Oct 9, 2017

@KNNSpeed nvm, when I turn picocom local echo (Ctrl-a Ctrl-c) on I can see the characters I typed in appears twice.

@ghost
Copy link

ghost commented Oct 9, 2017

Is the Pi echoing back anything? That might be why.
As I said I don't have a Uart cable or bare pi handy, so I can't do much in the way of checking. :/

@Piping
Copy link

Piping commented Oct 9, 2017

@KNNSpeed The code does work as echo back what I am typing. The picocom itself does not echo the character i typed. That's why I was confused.

@zhangboyang
Copy link
Author

@Piping What I did was copy (and only copy) bootloader to SD card, set up a DHCP and a TFTP server, put all boot files to TFTP root directory. Then when rpi2 starts up, it will try network booting.
However, I did it about a year ago and I can't recall the details. But it seems you have succefully used @KNNSpeed 's bootloader to solve the same problem. So the details is no longer useful. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants