dwelch67 / raspberrypi

Raspberry Pi ARM based bare metal examples

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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

zhangboyang opened this issue · comments

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

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?

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.

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

@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)

@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 +.

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

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

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

@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?

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).

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. :/

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

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.

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

Thanks @bluecereal!

@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.

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.

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].

@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!

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

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. :/

@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.

@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. :)